[
Lists Home |
Date Index |
Thread Index
]
> -----Original Message-----
> From: DuCharme, Bob (LNG-CHO) [mailto:bob.ducharme@lexisnexis.com]
> Sent: Monday, October 25, 2004 11:19
> To: 'ht@inf.ed.ac.uk'
> Cc: xml-dev@lists.xml.org
> Subject: [xml-dev] 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>
>
>
|
