Re: A radical finding on Using Qualified Names (QNames) as Identifiers in Content

James Clark <jjc@jclark.com> wrote 

> I think this is an important point.  When you have a document that uses 
> multiple vocabularies, you want to be able to declare the prefixes once 
> (typically on the root element) and have all the different vocabularies in 
> the document make use of those declarations.  If each application has its 
> own mechanism, then you would typically have to declare the prefixes 
> separately for each namespace island in the document.

But without a mechanism for saying which tokens in which content
are supposed to be Qnames, there can be no comprehensive common mechanism
anyway.   It goes beyond being a schema problem, it is a notation
issue: such-and-such an attribute value/element content uses such-and-such
a notation, and in that notation such-and-such tokens are qnames. 

In general, you cannot cut and  paste elements willy nilly even with
namespaces: in some DTDs their meaning may rely on inherited values*
(which no schema language lets us specify) or other context.
This rapidly moves into document-type-specific semantics.

On the other hand, since we already have PIs that are not PIs
(<?xml...?>), attributes that are not attributes ( @xmlns ),
XML Infosets that are not serializable to XML (XML infoset),
it would be consistant (if one were a cross-dresser) to also
attempt to have data content that was not literal data content because
it contained implicit prefixes. 

As another point in this, I note that W3C's XML Schemas adds
various attributes ( schema/@attributeFormDefault, attribute/@form
 schema/@elementFormDefault, element/@form) to handle when
specifying a name with no namespace from inside an element
(or attribute) that is using a default namespace.   To my mind, this
is a fairly confusing thing in XML Schemas: it certainly
makes markup simpler by not using prefixes, but then you 
get scoping interaction problems.  (In Schematron, the
XPaths must all use explicit prefixes, so this complication
never arises.) 

Cheers
Rick Jelliffe

*This was the problem that XML Fragment Interchange tried to solve.
I think Fragment Interchange (which I implemented and a friend also
implemented) may have been based on an inadequate premise:
when people cut-and-paste, they want to transfer information
items that is probably highly cohesive (from the cohesion/coupling
POV). For example, a cell, a whole row of a table, a whole
table.  So they don't need arbitrary context, because they
will typically only paste elements with the containing context.

Received on Tuesday, 2 July 2002 09:06:33 UTC