RE: intertwined specs

["Simon St.Laurent" <simonstl@simonstl.com>]

At 04:20 PM 2/16/01 -0500, Jonathan.Robie@SoftwareAG-USA.com wrote:
>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.

So we're in for multi-spec remodeling based on a large set of 'simple' data 
types.

>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.

Again, sounds like some rough sledding.

> > For one, MSL isn't published.
>
>It is published here:
>
><http://cm.bell-labs.com/cm/cs/who/wadler/papers/msl/msl.pdf>http://cm.bell-labs.com/cm/cs/who/wadler/papers/msl/msl.pdf 
>

Thanks!  So far as I know, that URI hadn't been published previously except 
on Philip Wadler's personal site.  (And I only just now found that link via 
Google, which has 148,000 other 'MSL' links.)

>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.

It's interesting to note that two of XML Schemas' competitors were built 
from formal models, however 'uncommon' a general rule that may be.

(DDML certainly wasn't built from a formal model, so I'll handily admit 
coming late to the opinion that 'starting from formal models can increase 
coherence', though I still limit that opinion to schemas, which are 
themselves performing modeling...)

>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.

Based on the list of things MSL leaves off, it looks like there is yet more 
rough sledding ahead.

>Well, you may appreciate the fact that more than one schema language can 
>be mapped onto the MSL abstraction.

I'll be interested to see how that works.  My lack of mathematical 
background makes me a poor judge, but I suspect that RELAX and TREX can be 
mapped using much less than MSL includes.

>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.

Perhaps, but extending those datatypes is pretty cumbersome at present, and 
not recommended in RELAX at this point.  I have to admit that I used to 
find the Datatypes spec far more pleasant than its Structures sibling, but 
it seems to share a lot of brittleness.  There are _lots_ of simple types, 
which makes me wonder from the start. Since I'm primarily a document kind 
of guy, though, it's not my specialty.



Simon St.Laurent - Associate Editor, O'Reilly and Associates
XML Elements of Style / XML: A Primer, 2nd Ed.
XHTML: Migrating Toward XML
http://www.simonstl.com - XML essays and books