A few thoughts

   I'm not truly up to date yet -- a week of conference can leave a
truly amazing hole in your email coverage especially on this
list. However, want to second Dan Rivers-Moore's comments on
processing, stylesheets, and link behavior. We had this discussion in
the abstract before the first XML-LINK proposal, but never reached a
clear resolution. The only form of link that _might_ have a claim on
being included in document markup is a transclusion (i.e. quotation)
link. And even there, there is much to recommend the stylesheet as a
mechanism for it.

   I won't go over all the arguments again, but note simply that the
distinction between element type and formatting behavior is _exactly_
the same as the distinction between link type, and link display and
traversal behavior. All the arguments of faithful representation, data
re-use, etc. go through in the new (i.e. liniking) domain, the same as
they do in the rendering domain.

   Second, I want to comment on namespaces. My feeling is that we
should _not_ try to address them in the first spec. for a number of
reasons:

   1. We may be able to make document instance syntax that reflects
the reality of namespaces, but we can't make compatible DTD syntax, as
we would lose SGML compatibility (Hard compatibility, though I was
opposed to requiring it in the initial design, is now a sine qua non
of XML -- it has affected virtually every decision taken in the spec
so far -- we can't go back and undo that now and also complete our
task on the kind of schedule we need if this work is to be useful.)

  2. We do not really understand the problems that we want namespaces
to solve: we want to "import" elements from other DTDs, but I don't
see agreement on what this means. Do we want to import their syntax or
semantics or both? It seems to vary with the proposer. Why can't
stylesheet sharing and current DTD design practices fix this problem?
I'd like to see a clear definition of what the problem is that
everyone can agree on, and I don't believe that will happen from the
discussion so far.

  3. We have not defined validity for "namespace-using"
documents. Well-formedness is a great thing that XML has given us, but
validity also has real uses, and one of ways that we satisfy SGMl
compatibility is by the notion of validity -- _if_ we define a
namespace mechanism we need a good definition of validity in the
presence of namespaces.

  4. We have _no_ practical experience with namespaces and markup
languages. The differences between SGML and computer programming languages,
the lack of a formal semantics for SGML (for good reason), and the
tight coupling of namespaces and formal semantics in the programming
language domain should all make us wary of trying to import ideas from
programming languages. I'd like some assurance that we know what
design space we should be working in, and what is effective _for
getting things done in documents_.

   5. Given the foregoing, standardizing a namespace mechanism now
would be standardization in advance of practical experience, agreed
common goals, and theoretical underpinnings. We might advance a
standard lacking any one of these three given a solid grounding in the
other two -- doing so in the absence of all three seems
foolhardy. This "Tripod theory" of standardization may be new, but it
seems reasonable to me. Finally, given that SGML itself has great
utility without namespaces, it seems unnecessary to rush into
something that we do not fully understand.

   -- David

"RE deleta est" (I never thought I'd get to say it!)

Received on Wednesday, 11 June 1997 14:10:06 UTC