Lists Home |
Date Index |
- From: "Simon St.Laurent" <email@example.com>
- To: XML-Dev Mailing list <firstname.lastname@example.org>
- Date: Thu, 07 Jan 1999 10:28:31 -0500
At 09:42 AM 1/6/99 -0500, you wrote:
>Simon St.Laurent writes:
> [about the highly secretive, smoke-filled XML Coordination group, aka
> The Syndicate]
> > I'd love to see a set of goals from the higher level group like the
> > working groups below it have so successfully produced. Right now,
> > the emperor himself is pretty invisible to the outside world.
> > There's no broad statement of what the XML family of standards
> > should look like when it reaches maturity (or puberty, even.) I
> > think everyone on this list has their own, usually incompatible,
> > vision of what XML should look like. A statement of what it will
> > look like might give us something better to work with, introducing
> > less complication in the long run.
>Actually, the problem is a little different. We all know what XML
>looks like -- it's described pretty clearly (modulo a few errata) in
>the XML 1.0 spec . What we're waiting to find out is what
>applications that happen to use XML will look like.
>Somewhere out there, there's a yet-to-be-discovered magic dividing
>line between what the W3C should and shouldn't regulate -- clearly,
>core XML 1.0 syntax falls on the W3C side of the dividing line, and
>just as clearly, the source code for a specific XML parser falls on
>the other side.
The problem that I'm describing isn't about where that dividing line is -
the W3C seems to have decided that reasonably well enough for itself,
though that's always contestable as well. The problem is that the W3C
doesn't appear (to those of us outside the smoke-filled room) to be taking
any initiative in regulating how its standards interact with each _other_.
XML 1.0 is at least the foundation, though namespaces cause problems with
much XML processing, as has been described repeatedly for the last 24
hours. Beyond that, however, it's not at all clear how XLink and XSL
relate to each other, how transformation relates to validation, either
traditional XML or using a schema, how XPointers and query languages will
be similar or different, and why, and how to best deal with the
'incoherence' of the multiple specs - XML's usage of entities and
notations, XLink's relationships of resources, and the xml-stylesheet PI's
blunt grabbing of a URL-based resource with MIME type specified in the PI.
This is a pretty ugly mess, and explaining it requires a lot of throwing
your hands in the air and saying "that's the way it is". It may mean a lot
more work for the W3C to clean it up, but it'll make for a far better
standard in the long run.
>Beyond obvious cases, though, we have the classic problem of how to
>regulate a market without killing it. We could take the Old
>Labour/New Deal approach and nationalise everything, we could take the
>Margaret Thatcher approach and privatise everything, or we could try
>to be Tony Blairs and please/disappoint everyone a little without
>taking any firm positions.
On the interactions between the specs, the W3C is definitely Tony Blair. I
don't think it works as well in technology as in 'real-world' politics, but
others may have different views.
Also, remember the W3C is barely a 'regulator' by its own terms - specs are
just 'recommendations'. I'd love to see a stronger W3C, but a much more
open one, but I can't say I expect to see that.
XML: A Primer / Cookies
Building XML Applications (February)
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)