[
Lists Home |
Date Index |
Thread Index
]
"Bob Foster" <bob@objfac.com> wrote:
| A document designer wants to allow foreign attributes and elements to
| be freely intermixed with those of the document type, as, for example,
| foreign elements and attributes are allowed in XML Schema and RELAX NG.
Combination at the schema or vocabulary definition level is not the same
issue as circumstantial combination in a document instance. One could use
the same mechanism (control attributes) to "mark" provenance, but other
techniques (such as in-schema differentiation through analogues of the
"role" attribute in the <title> example) become available too.
There is also ambiguity in what it means to "allow foreign material". It
could mean allowing material of effectively unknown provenance. (From a
validation perspective, merely the incidence of the foreign element is
noted; its internal validation is delegated to some other schema.) This
is the "bridge element" concept, where from this schema's point of view,
the element is a semantically empty container, with the moral equivalent
of a (#DONTCARE) content model. This allows the in-schema role to be
disengaged from whatever constraints are imposed on the element within its
own native schema.
Another case is where the "semantics" of the foreign element are imported
into the schema. Here, the foreign provenance is an annotative matter
only - the element type itself is now part of the schema and its native
vocabulary. I would expect the element type to be given an in-schema name
of some kind (just like naming any other component), and at worst, a
differentiating attribute used if "name collisions" are retained. Here I
don't see why the provenance (as opposed to the in-schema role) has to be
exposed in instance markup. Why should a schema not own its names? (And
if it can't, then why is there *any* schema claiming to own names?)
A third case is where a schema has no in-schema role for foreign material
that might be intermingled with its own constructs in a document instance.
It would follow, then, that the schema doesn't apply to the whole of the
document. And, from the perspective of a document per se, there is no
reason that the schema should be comprehensive. This is the "vocabulary
view" approach I've been talking about - it's a parsing issue only, and
completely solved by control attributes. The schema doesn't have to say
anything, because the issue of validating the entire document with respect
to this schema simply doesn't arise. (One would validate the "view" only;
semantically, it's up to a derivative schema, if one exists for the entire
document, to say in its documentation what it "means" to combine the
'view" with "views" of other prior schemas.)
| [...] Some convention needs to be established that will allow foreign
| items to be distinguished from any current or future "domestic" items,
| and to prevent name collisions among foreign annotations from different
| domains.
I think any convention that enforces the ability of any schema to own the
naming of its in-schema constructs and roles is enough. The annotation
could be an in-schema role-specifying attribute (which would typically
have to appear in instance markup) or a #FIXED control attribute (which
would not.)
| Both XML Schema and RELAX NG currently use namespaces as this convention.
| Can you suggest a better one?
Well, you and I may not agree on what constitutes "better"; let's just say
that, to me, few things could be worse than colonification of names;-)
I don't think the possibilities of attributes for annotation have been
exahusted.
|
