W3C home > Mailing lists > Public > xmlschema-dev@w3.org > November 2003

Re: extending schemas...more problems

From: Dean Hiller <dhiller@avaya.com>
Date: Thu, 06 Nov 2003 11:37:23 -0700
Message-ID: <3FAA94E3.3010804@avaya.com>
To: Dan Vint <dvint@mindspring.com>
Cc: xmlschema-dev@w3.org

I am not sure what you mean by code lists.  Do you mean, how is an 
enumerated list generates in code objects?  That is easy, typically it 
generates enum objects for you, and you can only set the enum on the 
object.(even in Java which doesn't really have enums until 1.5)
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:37:26 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:56:03 UTC