[
Lists Home |
Date Index |
Thread Index
]
DuCharme, Bob (LNG-CHO) wrote:
>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 ____________?
>
>
>
It makes life much easier if one has a name for that thing.
Why not call it element class. That's very consistent with XSD
vocabulary, because that word is used just for characters and once in
section 4.6 standing for substituion group (which is ok, because it
talks about an element class in the proposed sense).
BUT you always need to be aware of two things (which makes
identification with OO classes a fallacy):
- a class tells something about a tagname (or a set of tagnames) and a
*type* where a type is XSDs named sequence (thus classes are not types).
- a class only specifies trees that appear in a context. The root
element class describes root elements (the empty context) and other
element classes describe trees that may appear at specific positions
that depend on the context.
A context is the list of tagnames that appear from the path from the
root node to the "this" node (the root of all element information items
in this element class), plus (if the class is not in an all-groups) the
regular expression that characterizes which elements may come before.
>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.
>
>
>
They are, but the context of the declaration influence the scope of the
element class declaration.
Class make no sense without context.
Makes sense?
Interestingly, Java's inner classes pose a similar problem to
understanding, for pretty much the same reason - that the declaration
matters only in a certain scope.
cheers,
Burak
|
