Re: extending schemas...more problems

I only wish you were part of the team that was forming the standard I am 
using were most of the things defined look like so....

<xs:element name="something">
      <xs:complexType>
           <xs:sequence>
                 element stuff.
           </xs:sequence>
      </xs:complextype>
</xs:element>

 From what I understand, there is no way to extend that?  correct? 
 Pretty much set in stone.  A standards body should always use 
complexType or any's for private data, correct?  I personally prefer 
always using complexType as it is much easier to extend.  Luckily, the 
"element stuff" mostly looks like
 
<xsd:element name="something2" type="type"/>

so I can extend that type, but that is not always what I want.  I want 
to extend the elements.
thanks,
dean

Hans Teijgeler wrote:

> Hi Dean,
>
> In the (industry) standard <http://www.infowebml.org> I work on we 
> start with a data model. The entity data types of that model are all 
> defined as complexTypes. Any subtyping then is easy, in most cases by 
> extension, but if necessary by restriction..
>
> Then we derive the elements we need by typing them with these 
> complexTypes, and inherit all attributes from the top of the model 
> downwards.
>
> I give an example (don't pay attention to the awkward naming convention):
>
>  <xs:complexType name="thing" abstract="true">
>      <xs:attribute name="id" type="xs:string" use="required"/>
>  </xs:complexType>
>
>  <xs:complexType name="possible_individual">
>      <xs:complexContent>
>          <xs:extension base="thing">
>             <xs:attribute name="actual_individual" type="xs:boolean" 
> use="required"/>
>             <xs:attribute name="arranged_individual" type="xs:boolean" 
> use="required"/>
>             <xs:attribute name="whole_life_individual" 
> type="xs:boolean" use="required"/>
>         </xs:extension>
>      </xs:complexContent>
>  </xs:complexType>
>
>  <xs:complexType name="physical_object">
>      <xs:complexContent>
>          <xs:extension base="possible_individual"/>
>               <xs:attribute name="functional_physical_object" 
> type="xs:boolean" use="required"/>
>               <xs:attribute name="materialized_physical_object" 
> type="xs:boolean" use="required"/>
>               <xs:attribute name="spatial_location" type="xs:boolean" 
> use="required"/>
>               <xs:attribute name="stream" type="xs:boolean" 
> use="required"/>
>           </xs:extension>
>      </xs:complexContent>
>  </xs:complexType>
>
> <xs:element name="physical_object">
>      <xs:complexType>
>          <xs:complexContent>
>              <xs:extension base="physical_object"/>
>          </xs:complexContent>
>      </xs:complexType>
>  </xs:element>
>
> If you put this into Spy or the like you will see that the element 
> "physical_object" first inherits the "id" attribute of the complexType 
> "thing", then the three attributes of "possible_individual", and then 
> adds its own four attributes.
>
> I hope this helps somewhat, although I can very well imagine that I 
> have misunderstood your problem. I case you need more details, I will 
> be glad to give those.
>
> Regards,
> Hans
>
> ==============================
>
> 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
>> >
>> >
>>