Re: Namespaces, the universe, and everything

At 03:01 PM 19/06/97 -0500, David G. Durand wrote:

(And by the way, it's nice that this feels like a discourse again,
rather than a barroom brawl).

>OK, as I have said, this ammounts to either a loophole in the notion of
>validity, or a case where it needs to be extended. One of the reasons that
>I have been a bit nasty is that no-one has just admitted this up front. 

To be fair, in my posting of May 19 entitled 'Re: SD4 - Schema Format [fmt]'
I find the following:

>  The new types of schema that are being proposed include a lot of
>  things that are not covered by DTDs.  Thus we have three choices:
>   1. use XML syntax
>   2. radically extend DTD syntax
>   3. invent a new syntax
>  Of these, the first seems desirable, the second questionable, and
>  the third idiotic.

That was a whole month ago... any older and it'd be in Cuneiform.

>This sounds like a good application of MIME/multipart,
>but that's got a lot of unnatractive overhead too, so I'm still listening.

I agree that this does seem related to the problem that MIME/multipart is
trying to solve, and also agree that that's probably not the right path
for us.

>This is good as long as I can count on XML syntax to actually be a
>meaningful notion... Maybe meta-data in XML is worth a jump into the
>unknown. I'm not on the ERB, so I don't make that decision, but if that's
>the argument, let's not deny that we're doing it. And let's hear why having
>all meta-data in XML is a wonderful idea.

That decision is not really on the whim of the ERB.  We are a creature of 
the consortium, i.e. mostly the vendors and information providers; said
vendors & providers have looked at XML and said "document delivery yes,
when the browsers evolve a bit, but metadata right now!"  This process must
react to demand from the W3C base - right now the demand is for metadata.
Now, we are not required to go along slavishly with the flavor du jour,
but the metadata application seems like a good one and I at least see
no reason to resist.  BTW, if you do an "XML" search on DejaNews, you'll
see there's a big XML brouhaha going on over in EDI-land.  So far, they
haven't come in asking for changes...

As for why metadata in XML is a good idea, if it was just XML syntax
that alone would be good; cheap parsers, and fewer syntaxes is always
better than many.  But I at least want more - check out the recent MCF
proposal that Guha and I cooked up (or better, wait until next week 
when we'll have a redraft taking into account early reviews) - we think
it's possible for lots of radically different metadata to share not
only a syntax but a deep underlying data model and big chunks of
vocabulary, the benefits of which will probably not be lost on this group.

>I'm not opposed to the idea of namespaces, but the last minute rush is very
>worrisome, and the reasons behind that rush are _not_ being clearly
>presented to this group -- nor are the requirements and technical tradeoffs
>being presented.

I agree it's a rush, but then everything about XML has been done in 
a rush.  So far, it's worked pretty well.  About the requirements,
I can only disagree; I thought that Layman's original write-up was
pretty good; I took it on myself to poke around with my contacts,
and other ERB & I assume WG folk have been doing the same, and the
picture seems pretty consistent.  People want a wide variety of
schemata (including but not limited to DTDs) and they want to bundle 
chunks governed by different ones together in a delivery unit.  
That's about all there is to it.

>That was not the argument that I'm making. I'm saying that if AFs are a
>solution _at all_ then we should be careful about standardizing a new, only
>partially understoo mechanism in a  big hurry. If we don't get the
>semantics of the colon syntax right, then we've tied a long-term millstone
>around XML's neck. 

This concern is highly valid.  There is indeed a chance of going off
the rails; and I think if there's some fatal flaw in the colon-prefix
approach, this group is about the most highly qualified in the world
to spot it.  Looks like a win to me, but that's a judgement call.  Uh,
may I point out that the world is not at the moment exactly bursting
with commercially successful architecture-driven applications?  We're
taking a bet either way.

>I'm also worried about the inverse -- do namespaces force my DTD-loving
>application to deal with arbitrary foreign-namespace gunk that I can't
>anticipate? If DSIGs don't want to impose DTD stuff, that's fine by me, but
>if I want to fix a DTD, will namespaces force me into writing code to deal
>with "unexpected markup". This is a big step back from the reasons I
>usually want to write a DTD.
...
>I just want to know how I get a DTD that describes my document when the
>server jams a DSIG in there... Or be told straight to my face why not being
>able to get that is such a good idea.

This is a real problem.  I think that the chances of finding a traditional
SGML covers-the-whole-class-of-documents centrally-maintained 
laboriously-updated DTD that can parse everything that's going to
come over the wire are pretty poor.  Now I could indulge in 8879
sophistry and say that what comes over the wire is just a collection
of individual entities, and as long as you can validate the part
you care about, it's the task of some entity manager thingie to
pull that part out and treat it as the document entity and the others
as SUBDOCS or NDATA or whatever.

But I won't; I just think that the DTD is going to have to take its
place as one of the schemata that can be used to validate certain
portions of blobs of data coming over the wire.  Yes, it's different
from what we have now.

> I'm more concerned that if DTDs
>become optional, replaced by informal tag-salad specifications for diverse
>namespaces that we will be worse off than with HTML, because now it won't
>even be easy to format the sloppy tagging that will come in.

That's a fair concern; I don't share it, because well-formedness helps
quite a bit, and as I keep saying, people *like* the concept of
validation and of stringent schemata - they just want different things
than 8879 provides.

>I can see this as a fine strategy. Why can't the use the "." character and
>a suitable naming convention to uniqify tags for use with XML 1.0 and leave
>extending the language for later. This is essentially the : proposal, but
>avoids making the claim that we're adding a feature, and thus perhaps tying
>our hands once we know what we really want.

That was actually the initial proposal from Microsoft; I suggested
adding the ':' just because lots of people already use '.' in GIs.  

>Are the requirements (singly or in combination):
>
>  1. attachment of abstract semantics
>  2. unquification of names
>  3. attachment of unique names to short names in an instance
>  4. parsability by a one-pass parser
>  5. generatability on the fly with no discontinuous dependencies that
>would require buffering attlist declarations and the instance in progress
>while you do generation.
>  6. Conformance to notational prejudices of the engineers involved.

I think this is a good fair summary.  Although I would change "one-pass"
to "simple and lightweight".  I think SP is one-pass, and we'd like to
be able to use simpler technology.  Also for #5, it's worse than that,
because different chunks of metadata will be poured in by independent
modules, so each would have to read the subset to see what's already
there, munge it in nontrivial ways, and write it back out.
And I would put "(perhaps well-founded)" in front of "notational"

>And are the payoffs/risks:
>  1. XML if not used for meta-data will not be included in commercial
>web-browser software (eg MS, NS).
>  2. XML if not used for meta-data will be in browser software, but not
>anyplace else.
>  3. XML, if lacking namespaces, will be rejected by the W3C as failing to
>meet their needs.

No.  XML *will* be used for metadata.  Hence, because of the nature
of metadata, XML *will* have namespace/schemma wrangling machinery.  We 
couldn't stop that now if we tried.  That's why we're spending time
on this. - Tim

Received on Thursday, 19 June 1997 19:11:46 UTC