- From: Hans Teijgeler <hans.teijgeler@quicknet.nl>
- Date: Mon, 10 Nov 2003 00:54:35 +0100
- To: Dean Hiller <dhiller@avaya.com>
- Cc: Dan Vint <dvint@mindspring.com>, xmlschema-dev@w3.org
- Message-id: <3FAED3BB.6F5B1526@quicknet.nl>
Dean, The structure of our data model is completely defined in an XML schema with nothing but complexTypes. It works fine, although I had wished that XML schema had a bit more to offer, such as multiple inheritance. XML documents contain elements only, no complexTypes. These elements must comply with these complexTypes, but can be extended or restricted as compared with their role model complexTypes. These complexTypes bring some rigor in your work. So what is your problem? Regards, Hans ================================== Dean Hiller wrote: > 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 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 >> > > >> > > >>
Received on Sunday, 9 November 2003 18:50:06 UTC