Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Looking for an example of a name colliision
 "Bob Foster" <bob@o...> 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. 
|
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
|
|||||||||
