RE: is that a fork in the road?

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

At 04:24 PM 3/2/01 -0600, Len Bullard wrote:
>Who is offering what indigestible chunk?

A fair number of people unfortunately. W3C XML Schema is an indigestible 
chunk by itself - add an attribute to an element lately?  The requirements 
for XSLT 2.0 and XPath 2.0 suggest rather strongly that W3C XML Schema is 
going to become part and parcel of everyday XML processing.  Then there's 
this minor dispute over how best to (not) integrate scripting languages 
with XSLT.  All of these have substantial consequences which go beyond 
"well, no one's forcing you to use _that_ feature."

>Henry?  He is saying what the best and brightest
>said before him and since:  we are getting a
>complex mess because we didn't have a robust
>data model to begin with.

I'm not sure that trusting the best and the brightest to solve our complex 
messes with robust data models is such a good idea.  I think we might do 
better to let hard-working and somewhat more ordinary folks figure out how 
to use markup to solve their problems.

>   Which part of that
>is unreal?   All I am asking which I think
>may be at the heart of this is do we have
>to loop back into the base infoSet to fix
>things.  The pipeline metaphor can be
>seen as a series of infosets, each one
>different but building on what came before.

Except that it's not a simple pipe.  It's a complex set of substantially 
unpredictable interdependencies, where switching out components can cause 
data loss.  On top of that, these aren't exactly tiny components any more.

>Is that the idea?

Sure hope not, given the current tangle.

>   If the idea is to remove
>the bedrock of well-formedness, only the
>bits on the wire have to right to begin with,
>then I agree.

What?  What does "remove the bedrock of well-formedness" mean? And why 
exactly would you want to do that?  From my perspective, that bedrock is 
all that's really stable here.

>   At the bottom of this, all
>one gets is a well-formed character string.
>That won't be enough for some applications.
>The rounds in VRML proved it to me.  Justin
>makes it clear as Marrin did before him
>that type information is a REQUIREMENT for
>these apps to interoperate blindly.

It's not a requirement for a substantial and rather enormous set of XML 
applications.  Why inflict the rather controversial typing mechanisms of 
W3C XML Schema on every spec in sight?  Why assume that every developer is 
going to be delighted to have this functionality around?

Your requirements and my requirements are not the same, and your 
requirements may result in the creation of software that is in fact less 
useful to me.  Why not build the specs in such a way that you can use the 
parts you need WITHOUT inflicting real costs on me?

Right now, it looks like we're on the way to something perhaps even more 
complex than SGML.  That seems like we've taken a rather severe wrong turn. 
"Interoperating blindly" sounds like a really deeply bad idea, to 
boot.  I'd rather interoperate with my eyes open, thanks.

>If you are talking about XML Query, the
>jury is out on that.  I can see the sense
>of it from a perspective of how relational
>guys like to write queries.  I can see some
>giant overlaps with XPath and the expressions.
>I also see Jonathan saying over and over that
>both spec owners are working on a convergence
>to avoid messiness.  And I see them reiterating
>what Henry says so clearly:  without a data model
>it only gets worse from here.

Given the deliberate 'patchwork' nature of the XQuery quilt, I'm not going 
to pound on that.  However, I don't think the data model that's been 
proposed is healthy for XML, especially as it appears to be infecting and 
complicating far more than W3C XML Schema and W3C XML Query.

>So I am really missing your point.  Change seems
>inevitable.  Will it be ad hoc or planned?

Given the results of recent planning, I'm certainly cheering for ad 
hoc.  For this phase of development, I've got a lot more faith in 
competition than committee, and I'm counting on well-formed XML - and only 
well-formed XML - to provide a foundation for interoperability that lets us 
get through this probably contentious period.


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