Re: Update on namespaces

At 1:48 PM -0500 6/18/97, Paul Grosso wrote:
>1.  you would need to parse the start tag for all attributes (and
>    maybe check the internal subset and/or DTD) to determine if it
>    has a namespace-specifying attribute BEFORE you can determine
>    what the namespace is for the very element gi and attribute
>    specification list you just parsed!  If, in fact, you are going
>    to make any use of any declarations (DTD or internal subset),
>    you may discover after resetting the namespace that you've parsed
>    all the attributes wrong.  You might even discover that, in your
>    new namespace, you've got different arch forms so the attribute
>    you thought just changed your namespace doesn't really change
>    namespace in your new namespace!

This is a red herring. Namespaces were a proposed solution to the
requirement to attach semantics to elements in a DTD-independent way.
Architectural forms are a way to do that. There is no reason on earth to
think that an element like a single date might not be functioning in
several such semantic spaces. In fact, I expect that will be the rule in
document meta-data, so that the Dublin-core, Nescape Metadata, and other
info can coexist.

My DTD-parsing proposal shows how to limit the parsing required to a small
part of the DTD-subset, and for a bonus eliminates the RMD, which is
confusing and unlikely to be validated by the kind of software that might
be helped by it.

There is no reason that we need to solve the "namespace" problem by a
single architecture, rather than by allowing arbitrary architectures.
Without that assumption this objection does not go through.

>
>2.  by using archforms, you have no way to allow different names in
>    a start tag to come from different namespaces.  I'm not sure how
>    far we'd want to go here, but I predict there will be call for
>    having some attributes from one namespace and others from another
>    (Andrew and others have already shown some examples of this), and
>    going with archforms precludes ever being able to do this.

The examples are not that compelling, frankly. Most existing attributes
only make sense in the context of the element they are attached to, and any
new architectures can use sub-elements instead of attributes. This might
inconvenience a few applications (that are note widespread) but there's a
perfectly acceptable if verbose solution in sub-elements. And one of our
principles is that size of markup is _not_ a priority of XML.

So if we don't offer the mechanism that Andrew proposed, we can certainly
offer the representational power he claims to need. We need not undercut
the work we have done on syntax to solve the problems of semantic space.

>3.  if you go with something like a "namespaceid:" prefix, as long as
>    you've added : to namechar, a standard XML parser will be able to
>    parse the (fully namespace-qualified) document properly distinguishing
>    the distinct names (and, e.g., knowing what style sheets to use for
>    each element).  With arch forms, you have what I consider to be an
>    undesirable situation where the actual parsing of the document (as
>    opposed to just its application-dependent semantic interpretation)
>    is affected by the recognition of and proper reaction to the meaning
>    of the arch forms.  Said another way, I think archforms should only
>    affect the application-level semantic processing of a document, not
>    its basic parsing.

Stylesheet stuff based on namespaces would require more machinery that does
not currently exist, while the attribute approach is already supported by
all plausible stylesheet languages. Certainly by DSSSL, which is the
"official" XML candidate.

Arch forms leave the issue of validity in the DTD where it has always been.
The namespace proposals are the ones that propose a blanket exception to
the delcared syntax in a DTD. We should think long and hard about throwing
the DTD away for good, we may never get it back.

>I also tend to agree with Tim's "massive resistance in webland" comment,
>and I'm not sure I understand the comment attributed to James that a
>vanilla XML parser can handle the archform solution (how can it unless
>you assume it has built-in handling for the namespace archform semantic).

There's not one archform, so it shouldn't be a problem.

I don't think that it is a good idea to throw away what we know to be
useful (DTDs) based on so-called "massive resistance" from people who don't
know what they are talking about. XML is supposed to solve a set of
problems that this group understands pretty well. If that solution is not
attractive to the people defining the syntax of PICS tags, that (may) be
their loss. Weakening XML to conform to their prejudices (rather than
stated, justified needs) seems foolish to me. We've staked out a huge real
where XML can be useful (documents), so we need not agonize over the loss
of the market for other structured data type descriptions.

>If you need to refer to fancier combination of namespaces--I wouldn't call
>it "multiple inheritance"--(and I'm not sure we do, but we might want to
>allow for it later), that can be handled as follows.  Given that we use
>a notation declaration to associate the "namespaceid" name that comes
>before the ":", e.g.:
>	<!NOTATION nsid SYSTEM "...some URI/FPI/FSI sort of thing...">
>we can define a syntax that allows the system identifier to point to
>multiple namespaces.  One obvious syntax is that of FSIs which are
>structured identifiers that allow for sequences and/or or-groups of
>URIs and such.

As I pointed out above, some items (like document creation date, author,
title, etc) will probably have to be marked as part of multiple semantic
spaces to meet the meta-data needs of Dublin-core, Netscape MCF, Apple MCF,
and the many others that will be cropping up like weeds for the next few
years, while we figure out what we really need.

So the fact that we need this already is another argument _for_
architectures instead of GI-hacking.

   -- David

_________________________________________
David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________

Received on Wednesday, 18 June 1997 15:20:14 UTC