[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xmlbeans-dev
Subject:    Re: [PATCH 0 of 4] Summary of outstanding patches
From:       Wesley Leggette <wleggette () cleversafe ! com>
Date:       2009-05-07 5:42:50
Message-ID: C627DF0A.B80D%wleggette () cleversafe ! com
[Download RAW message or body]




On 5/3/09 15:52, "Radu Preotiuc" <radu.preotiuc-pietro@oracle.com> wrote:

> How about having one option for open content
> (setValidateAssumeOpenContent) and one option for attributes
> (setValidateAssumeAnyAttribute)? This way, if someone wants the Schema
> 1.1 behavior he can use just open content and you can use both for the
> effect you want.

I'm on board with that. I'll attempt to do it that way.


> 
> Also, could you send a separate e-mail with the fixes you had for
> SchemaTypeCodePrinter and a short description? I'd like to get the
> "straightforward" patches in first.
>

Sent as a series of three patches.


I've also re-sent the user types fix (this time it will apply to trunk).

Wesley

 
> Thanks,
> Radu
> 
> On Fri, 2009-05-01 at 20:43 -0500, Wesley Leggette wrote:
>> I would personally, for the schemas that I am writing, prefer to have full
>> validation by projection, including support for adding in attributes to
>> later versions of the schema. This provides more flexibility in the future
>> so that I can add attributes to elements as necessary without breaking
>> backward compatibility.
>> 
>> I would prefer to have both options, one that is clearly marked as
>> validation by projection, and the other that has the open content behavior.
>> 
>> Wesley
>> 
>> 
>> On 5/1/09 20:36, "Radu Preotiuc-Pietro" <radu.preotiuc-pietro@oracle.com>
>> wrote:
>> 
>>> Good point about the open content not applying to the attributes. However,
>>> do
>>> you need it for attributes? It's not only about the naming, but also the
>>> behavior. After reading the "open content" more carefully, it is in practice
>>> the same thing as "validation by projection" for elements or at least
>>> sufficiently close that I think it does not make sense to take a slightly
>>> different road than the one taken by the Schema WG.
>>> 
>>> So first, let's make sure that the behavior is the same as a subset of the
>>> "open content interleave" behavior (which I think it is). Then, the naming
>>> will fall into place.
>>> 
>>> Radu 
>>> 
>>>> -----Original Message-----
>>>> From: Wesley Leggette [mailto:wleggette@cleversafe.com]
>>>> Sent: Tuesday, April 28, 2009 5:44 PM
>>>> To: dev@xmlbeans.apache.org; Radu Preotiuc-Pietro
>>>> Subject: Re: [PATCH 0 of 4] Summary of outstanding patches
>>>> 
>>>> 
>>>> Radu,
>>>> 
>>>> Thanks, and yeah, I guess I hadn't shown the last one yet.
>>>> 
>>>> In addition, I have an additional fix for the VBP thing. I
>>>> will combine that and resubmit, so don't commit that one yet.
>>>> 
>>>> However, VBP and open content seem to be slightly different.
>>>> VBP seems to be slightly more lax than open content. While I
>>>> don't feel very strongly about the particular name, my only
>>>> concern is that open content may require different rules that
>>>> a conceptual "validation by projection". If we were to call
>>>> what I've done open content, it might end up being a misnomer.
>>>> 
>>>> Particularly, it is not clear to me that open content in
>>>> interleave or suffix mode allows arbitrary attributes. It
>>>> seems that open content only applies to elements. If this is
>>>> the case, it should be noted that VBP does not have this design.
>>>> 
>>>> Wesley
>>>> 
>>>> 
>>>> On 4/28/09 15:42, "Radu Preotiuc-Pietro"
>>>> <radu.preotiuc-pietro@oracle.com>
>>>> wrote:
>>>> 
>>>>> Wesley,
>>>>> 
>>>>> I have just commited the user-types patch yesterday, SVN revision
>>>>> 769119 (feel free to do a diff if you want to confirm that
>>>> everything is in place).
>>>>> 
>>>>> The "validation by projection" part I am ok with and will commit it
>>>>> soon also, but I want to change the name to something like
>>>>> "assumeOpenContent" to be in line with the terminology adopted by
>>>>> XMLSchema 1.1 for a feature which I think is equivalent.
>>>>> 
>>>>> The "imported patch annotation-fixes" is new to me: is it
>>>> just adding 
>>>>> @Deprecated annotations for 1.5-compatible code? If so, obviously I
>>>>> agree with it and will commit this too.
>>>>> 
>>>>> Thanks,
>>>>> Radu
>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: wleggette@cleversafe.com [mailto:wleggette@cleversafe.com]
>>>>>> Sent: Tuesday, April 28, 2009 12:36 PM
>>>>>> To: dev@xmlbeans.apache.org
>>>>>> Cc: wleggette@cleversafe.com
>>>>>> Subject: [PATCH 0 of 4] Summary of outstanding patches
>>>>>> 
>>>>>> What follows is a summary of my outstanding patches. Please let me
>>>>>> know what I need to do to get these accepted.
>>>>>> 
>>>>>> Wesley
>>>>>> 
>>>>>> 
>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
>>>>>> For additional commands, e-mail: dev-help@xmlbeans.apache.org
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
>>>>> For additional commands, e-mail: dev-help@xmlbeans.apache.org
>>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
>>> For additional commands, e-mail: dev-help@xmlbeans.apache.org
>>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
>> For additional commands, e-mail: dev-help@xmlbeans.apache.org
>> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
> For additional commands, e-mail: dev-help@xmlbeans.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org

[prev in list] [next in list] [prev in thread] [next in thread]