RE: infinite depth to namespaces

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

On 30 Aug 2001 15:30:21 -0700, Tim Bray wrote:
> Matt Fuchs et al are throwing around interesting experimental
> ideas about getting a cleaner mapping between names and definitions,
> which is a complex and non-obvious problem, and more power to
> them.  But I don't think that all the PSVI theorists in the world,
> laid end-to-end, are any threat to the everyday working usefulness
> of XML. -Tim

I really wish I had any hope in that description of the problems we face
here.  It's optimistic, diplomatic, and friendly, but it requires far
deeper faith than I can find.

To go back over the arguments presented here:

> Don't sweat it.  The only normative definition of XML is syntactical.  
> The only normative definition of namespaces is syntactical.  These
> definitions are implemented by tons of interoperable software.

Those normative definitions are implemented by tons of partially
interoperable software that usually but not always presents a vision of
the document in the manner the developer expects.  XML 1.0 itself had
plenty of creative gaps, mostly around options for non-validating
processors[1], and Namespaces in XML has added plenty of tripwires we've
spent years addressing.  (RDDL solved one tiny part of the problem, and
I count that as a major achievement.)

So yes, there is lots of mostly interoperable software out there which
works just fine most of the time.  Unfortunately, when it doesn't work
(what the hell just happened to my XLinks, I mean my attribute
defaults?), users are rarely well-equipped to figure out what happened.

The fact that the normative definitions are syntactic gives me great
hope.  The fact that users and developers and spec-writers have proven
capable of reading incredible things into that syntax dampens that hope
considerably.

> The 
> Infoset, simply because it has come after XSLT and XPath and DOM
> and SAX chronologically, is an afterthought.

For me, certainly.  For most of the programmers I talk with, (much as it
pains me to admit it), the Infoset is really the thing.  They're not
used to thinking in syntax, so they don't.  For these folks, the Infoset
is everything, and anything which threatens to give them a "wrong"
Infoset is a problem to avoid, once recognized.

> The PSVI is an 
> elaboration of that afterthought.  Working programmers are generating 
> XML with various flavors of print() statement and reading it through a 
> variety of interfaces (including Notepad :)) and not apparently having 
> too much difficulty.

Some working programmers are generating XML with print().  More and more
I find programmers generating XML through DOM (read broadly to include
MSXML) or JDOM, and occasionally with SAX.  I keep hearing about people
writing Visitor classes that generate DOMs from sets of objects, and XML
as only a serialization of an Infoset.  (If Don Box is watching, I'm
reasonably sure he's smiling to hear this.)

I can't figure out why some programmers feel that syntax is more
difficult, but it may just be that they're not really acquainted with
it.
 
> XSDL and its competitors are an unqualifiedly good thing.  They
> provide immensely better expressive hooks for the language designer
> and for the authoring program that wishes to support a human in 
> direct creation of XML content.

"And its competitors" gives me hope.  I have to question references to
W3C XML Schema as an unqualifiedly good thing, especially in the context
of the current namespaces discussion.  It seems quite clear that W3C XML
Schema has blessed, probably even fortified, a namespace practice best
described as "controversial".

> The data typing system will have
> lots of supporting libraries which will facilitate all sorts of
> interchange tasks.  So let's not diss the contribution of the schema 
> folks.

Uh, well, I've been working on this Regular Fragmentations stuff[2], the
political message of which is pretty much a diss of the "contribution of
the schema folks", and happily at that.  It's possible to do lots of
interesting work in the syntactical noise without working with the
T-word, something which I think many T-folks prefer not to recognize.

> The overwhelming majority of real XML deployments at this time do
> not do runtime DTD validation, and it's hard to believe that 
> they'll do runtime schema validation.  In very many cases the
> knowledge that is encoded declaratively in schemas ends up being 
> re-encoded procedurally in compiled code, along with all sorts of 
> other business-logic sanity checks (e.g., is this a real employee 
> ID number?).  I do think however that there will be lots of callouts 
> to libraries built around the XSDL data types, for doing validation 
> and conversion at run-time.  

Should be a beautiful world for some folks, but I don't think that
normative syntax is going to help too awfully much with keeping the
Infoset folks from painting XML into something far grander than syntax.
The developers writing the business logic are eventually going to get
aggravated about writing code that duplicated previous checks, and I
suspect they'll respond by insisting that schemas start supporting more
business logic.  (That's been happening for a while, it seems.)

Perhaps eventually we'll fall back to syntax, but I expect it'll be a
reasonably long wait.  Until then, I guess I should keep writing code
expressing a different vision and finding ways to cash in on the
unending complication of XML.  The latter funds the former, a strange
kind of engine.

[1] - http://simonstl.com/articles/acminterop/interop.html
[2] - http://simonstl.com/projects/fragment

Simon St.Laurent
http://simonstl.com