[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Schema concepts
"Henry S. Thompson" wrote: > > [sorry for empty reply a moment ago ;-[ I thought you were already running out of arguments :-) > Sorry, I was moving too fast this morning, you're right. > Here's a corrected fragment But with the changes and the reuse option, your example seems more or less identical to my initial one....? > > > <element name="shipTo" type="po:Address"/> > > > <element name="billTo" type="po:Address"/> > > > > That would also be possible with (abstract) elements instead > > of types, e.g.: > > > > <element name="shipTo" source="po:Address"/> > > <element name="billTo" source="po:Address"/> > > Assuming you meant > > <element name="shipTo" equivClass="po:Address"/> > <element name="billTo" equivClass="po:Address"/> > I assumed equivClass and source would be merged when the element/type distinction is removed. > where po:Address is now an abstract element, no, that's asserts they > are indifferently substitutable for 'Address' wherever it is allowed > in a content model, which is _not_ what you mean. Yes, that's exactly what I mean. Please note that your po:Address cannot be used anywhere in a content model directly since it is a type. You can avoid global visibility of derived elements by declaring them locally. Also, nothing hinders you from deriving from Address wherever you want to avoid that other elements derived from Address are inserted. Example: <element name="address" source="po:Address"> Since address is a subclass of po:Address, you cannot substitute it by shipTo/billTo. > (...) When I define a struct or a class in C++ > no-one confuses that with declaring a variable to > contain _instances_ of that struct or class. Can you explain the meaning of "equivClass" in this context? OK, I agree that I need variables, types, and instances in an OOPL. But would you say that the following is impossible: 1. rename all types in an XML schema that conflict with element names, 2. merge the type and element functionality, and 3. the schema would still be operational? (and could probably become much shorter by removing some then unneded intermediate former types) Best regards Stefan -- Stefan Haustein University of Dortmund Computer Science VIII www-ai.cs.uni-dortmund.de *************************************************************************** This is xml-dev, the mailing list for XML developers. To unsubscribe, mailto:majordomo@x...&BODY=unsubscribe%20xml-dev List archives are available at http://xml.org/archives/xml-dev/threads.html ***************************************************************************
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|