[
Lists Home |
Date Index |
Thread Index
]
Is there a missing layer in generic tools (and standards) for XML?
One way of approaching XML is as a tree of nodes of terminal
atoms. This is more or less the view that comes out of the
XML infoset.
But another way of approaching it is as a series of scoped
properties applying to data, where the properties of data at any
point are all the elements and attributes of the parent and
ancestors. This kind of scoping can be found in SVG or XSL:FO,
for example.
In the first view, the question of interest is "what are the
properties (element name and attributes) of this content?"
while in the second view, the question of interest is "what
properties are in scope for this content?"
The generic XML standards at W3C provide few
generic mechanisms to work with scoped data of documents:
perhaps XPaths ancestor-or-parent::*[1] is the only
one that springs to mind. (Local element definitions in
XML Schemas don't count: they say nothing about
significance.)
Looking at the various W3C specs, I think we can see that
XML advances on HTML by allowing user-defined properties
instead of standardized ones...except for scoped properties.
For these, the attempt is still to get by, trying to enumerate
a fixed specific vocabulary that can cover each case as it arises:
xml:lang, xml:space, xmlns, xml:base and so on.
The attraction of generalized markup systems is that
we can model all sorts of data and use generic processors
to manipulate them. But if the standards for generic
processors (schemas, queries, transforms, etc) only
provide one aspect, then we are left with XML documents
which require specific tools to use.
Conventional wisdom at the moment is that scoped documents
are naturally suited to specific, optimized implementations:
you wouldn't expect to implement SVG using a generic DOM
for example. But I wonder if this creates a gap in our
toolsets/standards/technology. The conventional wisdom is
based on the current absense of any way to specificy scope.
What would this missing layer look like? I am not sure. Perhaps
it might be a simple as a simple schema language that
sets the effectivity of elements and attributes: for example
to say that the attribute @size applies to all of certain children
or namespaces. Then an API could query an element's effective attributes,
as a kind of augmented infoset very different to the PSVI of XML
Schemas or XQuery.
Or perhaps it could be done in a similar fashion to SGML's #CURRENT
default declaration for attributes, to say that a value defaults to the last one
along some axis. The API still queries in terms of attributes, but the implementation
looks along the appropriate axis, providing a different view of the document.
A schema language with some kind of scoping mechanism would allow
a much more optimized implementation rather than relying on the
scoping to be built into the query. (Indeed, one might say that if
a parent does not provide any scoped properties for its child, there
is no reason for an API to be able to locate the parent from the child.)
Cheers
Rick Jelliffe
|
