[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: intertwined specs
- From: "Simon St.Laurent" <firstname.lastname@example.org>
- To: Jonathan.Robie@SoftwareAG-USA.com, email@example.com
- Date: Fri, 16 Feb 2001 21:47:25 -0500
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
>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:
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
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