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


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] syntax, model

[ Lists Home | Date Index | Thread Index ]

mc@xegesis.org (Mike Champion) writes:
>You're "sharing data models", at least in the sense
>that John Cowan uses the term, whenever you use
>XPath/XSLT or XQuery ... or WikiML or something like
>it to edit some text that will get converted to XML
>.... or DOM or CSS to work with a non well-formed HTML

When I'm working in XSLT and running my stylesheets on multiple
processors, yes, I'm sharing a simple data model, and yes, it _mostly_
works.  (Unless I happen to be in IE with its freaky mixed-content
whitespace discard policies, though maybe they finally fixed that.)  The
XPath data model - for 1.0 at least - was simple enough to work, largely
because it didn't create anything new.  While I find it frustrating
because (IMHO) it discards too much, it sort of mostly does the job.

The XPath 1.0 data model is the only one I can take seriously as "a
shared data model that works".  It is so small a data model - even
compared to CSS or DOM, never mind OWL/RDF - that I have a hard time
taking its success as any grand claim about the value of data models. If
anything, I take its success as a sign that humility makes
implementation simple enough that most people can get a spec right most
of the time, especially if the spec is written before the
implementations take root.

> That's what bugs me about Tim's rather sweeping
>assertion in the TAG list.  

I found your later assertions about the value of data models deeply
unfortunate, really demonstrating how standards work has really produced
results that are difficult to implement, understand, and use. The W3C
has been drilling itself further into the ground for years, sure.  Why
enshrine that in the arch doc?  Almost as bad as pretending
SOAP/WSDL/UDDI has anything in common with the World Wide Web.

>I can't reconcile the idea that shared data models are
>"non-interoperable" or "pernicious" with the real,
>practical success of XSLT, DOM, CSS, etc. Likewise, I
>don't see much merit in the argument that the very
>real warts on these things have to do with their being
>defined on a reference data model rather than concrete

Sorry, Mike.  I've wasted too many hours on DOM and CSS interop to
consider them a success.  What success they've achieved has required
enormous effort from implementers.  I'm glad those folks have done the
work - and annoyed with those who've taken sharing less seriously while
claiming to comply - but it still seems like they do an awful lot of
mapping between "what CSS tells me/DOM calls look like" and "what the
actual guts of my system are".  

The warts are real, and not just odd artifacts of vendors run amok.  Are
they avoidable?  

For CSS (and HTML, XSL-FO, SVG, etc.), probably not.  The shared model
is an unfortunate but real cost.  CSS and especially XSL-FO suffer
mightily from model vocabulary that frequently obscures how you actually
do formatting, and that probably could have been avoided, but otherwise
their only real value is in shared semantics attached to a particular
syntax.  Maybe "tell me what it looks like" instead of "describe a
formal model" can help there.  HTML and SVG mostly managed to avoid
that.  I think XForms got tangled in it, though I hope their model is
modest enough to make it.

For DOM, I suspect the whole process was a mistake that grew and grew.
It produced some nice results in browsers that cared to implement it in
an HTML context, but beyond that, I suspect it did little except retard
the development of more usable alternatives.  There was an enormous cost
to sharing that data model.  (I recognize that it was the misfortune of
the committee members to share that cost.  I wish they'd been weaker and
pulled the plug, however.)

>On the other hand, if we mean something very different
>by "data model" in the abstract sense of the XPath
>data model and in the specific sense of some model of
>an order or invoice or a syndication feed or whatever,
>that may explain a lot of the angst surrounding this

That angst feeds in to the more general angst directly.  I have a little
patience for the very general model of XPath, less patience for CSS,
even less for DOM, less yet for the PSVI, and none whatsoever for the
notion that we're sharing data models when I send an XML invoice from
myself to another party.

The further you get from the syntax, the deeper the poison runs.


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS