[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] 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
|
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
|