OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: intertwined specs

Title: RE: intertwined specs

Simon wrote:

> Does the data model fit XPath as it currently exists? 
> Or will XPath need retrofitting?

XPath is based on four datatypes, and provides elaborate rules for converting any node or nodeset to each of these datatypes. These four datatypes do not exist in XML 1.0, and they are not the datatypes of XML Schema. I believe that XPath will have to adopt the XML Schema simple datatypes, define operations on these datatypes, and define consistent casting rules for these datatypes.

> Does the data model play nicely with the Infoset and DOM,
> which both have slightly different views than XPath?

The data model is more closely related to that of XPath. In fact, I think it would be good if XPath and XQuery could agree on one common data model. This is not really incompatible with the infoset - both XPath and XQuery define a mapping from the infoset to their data models. As for the DOM, I think it is unfortunate that XPath chose to handle some things in ways incompatible with DOM Level 1. Once there were two incompatible models, XQuery had to choose which one to be compatible with. The XML Query datamodel is obviously based on XPath's data model.

>> In the long run, I think that the Schema Formalization effort, based on
>> the earlier MSL work (), is a key player in allowing the data model and
>> algebra to be defined in terms of Schema types.
>> So what is the problem?
> For one, MSL isn't published. 

It is published here:


> For two, MSL is an after-the-fact fitting
> of formalisms to an ad hoc spec which hasn't
> received rave reviews for clean
> and consistent implementation.

Well, MSL is, in fact, an after-the-fact formalization. Since most specifications are not based on formal models, this is not uncommon, though I agree that is generally best to be working with a formalism earlier in the process. Personally, I find a good set of use cases and a formal model a useful starting point for a formalization.

The fact that it is hard to discern a simple formal model by reading the XML Schema specifications is precisely the reason that MSL is necessary. Or rather, Schema Formalization, which is the name that ths XML Schema WG is giving to this, now that the work is being done within the XML Schema Working Group.

> Finally, I'd suggest that the regular expressions language which is
> currently part of XML Schemas be pulled from that spec much as XPath was
> pulled from XSLT, and given a separate publication for easier reuse.

Sure, that makes sense.

> I'd suggest that W3C specs provide hooks for various
> schema languages - as the DOM working group appears to be doing

Well, you may appreciate the fact that more than one schema language can be mapped onto the MSL abstraction. I also think that the simple datatypes of Schema are going to be pervasive - not only in the W3C data models, but also in TREX and RELAX.