[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: RE: XSD and "elements"
> -----Original Message----- > From: DuCharme, Bob (LNG-CHO) [mailto:bob.ducharme@l...] > Sent: Monday, October 25, 2004 11:19 > To: 'ht@i...' > Cc: xml-dev@l... > Subject: RE: XSD and "elements" > > > Henry Thompson wrote: > > >>what is an element declaration declaring > > >the REC never needs to refer to that concept > > Well, I suggest that "manages to avoid" might be more > accurate than "never > needs to." I understand that an XSD schema can have a top > level declaration > for para and two other local ones. In language consistent with XSD > vocabulary, can we fill in the blank and say that each of these three > declarations is declaring a ____________? > > Otherwise, you've got a spec that describes declarations > without making it > clear what they're declaring (element declarations aren't declaring > elements?), which I find it pretty confusing. I think it is appropriate for XML 1.x to have "element types", given that it does not have (structured) types. In XSD, types subsume the role of XML 1.x's element types, except that they do not assign a name to the element information item. Personally, I am happy with an "element declaration" declaring a class of element information items having common characteristics (e.g., the [namespace name], the [local name], and the context in which they are allowed to occur). I don?t think we need another term. If the rec had introduced a term for such a class (say "element type"), I think this might have resulted in confusion between a "type" and an "element type". The difference between these two concepts is subtle and might have been hard to explain, and I guess people would have spent time wondering why a language needs both concepts, and what a type is, after all, if it is not an element type or an attribute type. I think the rec is clearer as is, without the additional concept. Interestingly, in ASN.1, one talks about (data) types, and there is no concept of "element" at the abstract level. Instead, there is the concept of component of a structured type. We say that a sequence type has (named) components, or that a sequence-of type has one (named or unnamed) component. When the XML encoding rules are used, each component value gets encoded as an XML element (information item) or attribute (information item). So, in ASN.1, types are more fundamental than elements and attributes, in that types (and their components) live at the abstract level, whereas XML elements and attributes live at the encoding level (XER encoding rules). The XSD conceptual model is more complex than the ASN.1 conceptual model because it has both type definitions and element/attribute declarations, and they interact in many ways. The standardized mapping from XSD to ASN.1 (X.694) supports the additional complexity but relegates it at the encoding level, leaving the type-definition syntax free of those concerns, and resulting in a clean layering. Alessandro Triglia OSS Nokalva > > Bob > > > ----------------------------------------------------------------- > The xml-dev list is sponsored by XML.org <http://www.xml.org>, an > initiative of OASIS <http://www.oasis-open.org> > > The list archives are at http://lists.xml.org/archives/xml-dev/ > > To subscribe or unsubscribe from this list use the subscription > manager: <http://www.oasis-open.org/mlmanage/index.php> > >
|
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
|