Re: extending schemas...more problems

JAXB aside, there are problems if you are doing this regardless.  Say 
peer A is on version 1 and does no restriction and sends key="ABCDE". 
 peerB follows the extendedschema.xsd plus originalschema.xsd.  The 
extended schema decides to restric key to 3 digits.  peerB will now 
reject peerA's xml request, event, or response(whatever you are doing here)

Same goes for client-server.  Doing a restriction is like deprecating a 
method in Java.(Notice sun hasn't deprecated methods for years!!!!) 
 Take it in this light.  Since restriction is deprecation, everyone must 
be very careful because deprecation ALWAYS breaks backwards 
compatibility.  You just can't have that.  Adding to stuff is ok.  You 
can add to your hearts content, but as soon as you want to restrict or 
deprecate something, you are going to have many people jumping up and 
down saying "I was using that".  I guess I am telling you there is no 
solution here but to say version2 is not backwards compatible with 
version 1 for this reason.  

One thing you can do to alleviate this problem though is communication 
of capabilities to find out if something you use is not backwards 
compatible.  It could be seen to break one protocol down into many and 
to have an exchange at setup to see what is backwards compatible and 
what is not.  Overall though, Sun has the best method yet, just don't 
deprecate anything.  I hope this was somewhat enlightening.
thanks,
dean

Dan Vint wrote:

> Thanks for an additional idea, but we also want to validate with the 
> schema directly. Also how do you handle restriction with your idea? 
> and what happens with code lists defined as enumerated lists - I need 
> both extension and restiction of these values.
>
> ..dan
>
> At 09:24 AM 11/6/2003 -0700, Dean Hiller wrote:
>
>> Hi Dan, (I might have a possible answer to your question below also)
>>
>> I kind of disagree here.  Most standards (if not all) should be 
>> extendable(I hope I don't start a flame war with this...it is just an 
>> opinion).  There is always some feature customers want and the 
>> standard doesn't support it but your company still has it.  What do 
>> you do?  Tell the customer, sorry, the standard doesn't support it 
>> AND we can't extend the schema.  Any time any part of any schema is 
>> non-extendable, I think it is a mistake.  Even XHTML should be 
>> extendable such that you can add your proprietary features that 
>> customer wants.  Later on, that same company is obviously going to be 
>> trying to push those same extensions into the standard, but meanwhile 
>> they have to be able to extend it.
>>    I am open to other examples though of which I am not aware of.  I 
>> cannot think of any examples though in which I would not want an 
>> extendable schema.
>>
>>    Have you guys considered (Api for XML Binding) AXB or JAXB is you 
>> are using Java.  There are others for C++ and stuff.  What is really 
>> nice about those is you don't have to do any XML.  All the companies 
>> just use libraries.  A Car represents a <xsd:element name="car">.  
>> When someone wants to extend the car, they use <xsd:element 
>> name="CompanyXcar"> and a CompanyXcar object is generated.  When the 
>> extra elements in CompanyXcar go across the wire, they can be ignored 
>> by someone who only cares about the car element as they will only see 
>> the car element.  To use this, you have to do extension and just 
>> extend the car.  No companies have to do XML really again except when 
>> sniffing the network or something.  If I am totally missing the point 
>> here though, let me know.
>> thanks,
>> dean
>>
>> Dan Vint wrote:
>>
>>> They may not be mistakes!
>>>
>>> The organization may not want their spec to be extended, this is 
>>> sort of like setting block on everything only easier.
>>>
>>> I think the bigger problem is what my organization is running into. 
>>> We want to have a standard document instance without specifying 
>>> which way someone might actually choose to extend the standard - and 
>>> we want to make sure that tight validation of element content is 
>>> possible.
>>>
>>> We have come down to 3 methods we are evaluating to extend the spec 
>>> based upon schema techniques:
>>>
>>> 1) substitution groups
>>> 2) derivations
>>> 3) redefine
>>>
>>> We have different people that like each of these approaches. The 
>>> problem is that depending upon which method I use, the resulting 
>>> data stream is different. Method 1 ends up having a namespace prefix 
>>> on the containing element, Method 2 requires the use of xsi:type and 
>>> method 3 ends up with just the new elements having a prefix.
>>>
>>> Because of this situation we will have to define a "standard" 
>>> extension mechanism and setup our schemas according to that 
>>> preferred method. This has already caused weeks of debate and 100's 
>>> of email trying to decide the method to use.
>>>
>>> Now add the problem that we want to allow restriction (redefine is 
>>> the only method that supports this) and we have a need to extend and 
>>> restrict enumerated code list data types and we have a real mess.
>>>
>>> ...dan
>>>
>>> At 04:00 PM 11/5/2003 -0700, Dean Hiller wrote:
>>>
>>>> uh-oh, I ran into another problem with extending schemas.  The 
>>>> standards committee created an element
>>>>
>>>> <xsd:element name="Car"/>
>>>> .....complexcontent here
>>>> </xsd:element>
>>>>
>>>> Now I can't extend this with extensions and make a CompanyXTypeCar 
>>>> to put more data in for the features we have that are not yet 
>>>> handled in the standard.  This keeps happening over and over every 
>>>> time I go to a new standards.  Is there any was we can get the w3c 
>>>> to change this so elements are extendable too so it becomes 
>>>> impossible for standards bodies to make these mistakes????
>>>> thanks,
>>>> dean
>>>
>>>
>>
>

Received on Thursday, 6 November 2003 13:36:02 UTC