Suggestion for W3C wide context mechanism

Greetings!

Having waited and waited for the final release of the xpointer to no avail, I 
would like to make some comments and a suggestion regarding the problems, at 
least as I perceive.

Probably the greatest stumbling block (and the most heated discussions on 
this list and elsewhere) appears to surround the dreaded notion of QNames.  
However they came about, QNames at one level solved the problem of providing 
readable constructs whilst at the same time a mechanism for globally 
identifying the meaning of a particular QName.  Not necessarily the best 
technical description of what they do, but largely correct I think.

It is ironic of course that this very feature has come back to haunt us in 
the xmlns() scheme, particularly with regard to user defined (xpointer) 
schemes. Indeed a feature originally designed to make things readable and 
clean has become so involved as to virtually render XPointer unworkable (and 
their are grave risks that other standards could fall into this minefield as 
well).

It seems to me that their is a broad problem at almost a philosophical level 
running through the W3C standards, and that relates to _context_ and 
processor independence.  Processor independence is important for any number 
of reasons which don't need to be covered here, yet I would argue that a 
broader discussion on the meaning of context needs to occur for many of these 
problems to be resolved.

I would make the assertion that all processors operate in a context of some 
sort, even if that is a global context.  I would further assert that many 
operations occur within a shared context, and what is lacking in the W3C 
standards is a mechanism with which to share this context.  And finally, I 
would argue that such a mechanism has the potential to minimise the impact of 
what appear to be questionable architecture choices, which nevertheless we 
may have to live with. [Whether we have to live with them not being the 
subject of this discussion].

So it would appear to me that there is room for a "meta-processor" standard, 
a standard and somewhat extensible means by which the various processors can 
communicate information with each other.  I propose that this information be 
described as a "context" and their is an enormous body of precedence for this 
name ;-).  There would be a requirement that processors be able to start 
independently (as they do now) and establish this context themselves, and 
they would also be able to start with a particular context as a starting 
point.

The one clear example of how this would be useful, is of course namespace 
declarations.  By necessity, the xmlns() schema identifies namespaces in a 
way which is not similar to the way they are declared in an XML document.  
Which is as it should be.  Nonetheless, the task is the same, and worse 
still, often forces duplicated effort in the real-world for no apparently 
good reason.  As has been raised elsewhere, say I have 10 XPointers in an XML 
document that each require 3 namespaces, I now have added 30 xmlns 
declarations.  I think that the polite word for such a situation is "ugly".  

A context mechanism would allow for the inheritence of namespace information 
from the parent processor, XML in this case, but it could be any processor, 
or it could be an external context managed by the user of the processor.

The advantage of this approach is that much of the namespace machinery in 
xpointer for example becomes optional in the presence of a suitable context, 
thus greatly enhancing the readability and simplicity of such a mechanism.

The only disadvantage I foresee is that the XPointer becomes non-atomic, but 
only in the sense of the human interpreter.  This becomes problematic if a 
user wishes to copy an XPointer, but their are problems doing this anyway.

No doubt there are other problems with this approach, as I feel sure it has 
been discussed before, but can find no reference to it.

Best Regards
Ross Lamont

Received on Tuesday, 29 July 2003 21:30:48 UTC