[
Lists Home |
Date Index |
Thread Index
]
Fascinating proposal. It reminds me of the factorization of decision from
code way back in the era of rule-based systems. You can achieve an
appropriately scoped statement of structure/behavior that is more succinct
and, is some cases, more flexible and controllable, when the expressions
that apply the structure/behavior are neither embedded in the data/code, nor
rely on some implied context (e.g., that the validity of an element's
attribute relies on the validity of the attribute in its parent,
recursively). It might even help with the mess of cancellation semantics
that derivation by restriction can bring.
You also can more easily achieve a collection of "views" of the data, given
different sets of scoping rules.
The questions that arise are: How powerful and complex are the scoping
statements? Can the average person make the transition from a hierarchically
embedded definition of scope to a separable overlay of scoping rules? Will
the rules ultimately look like an explicit replication of the implied path
expressions and thus become all the more tedious to maintain? Or would they
tend toward some more concise expression?
Looking forward to seeing where this will lead...
Mark
-----Original Message-----
From: Rick Jelliffe [mailto:ricko@allette.com.au]
Sent: Monday, July 29, 2002 12:09 PM
To: xml-dev@lists.xml.org
Subject: [xml-dev] Scopes trial: Is there a missing piece in the XML
puzzle?
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
-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>
The list archives are at http://lists.xml.org/archives/xml-dev/
To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl>
|
