Re: extending schemas...more problems

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 12:14:10 UTC