Re: Update on namespaces

Considering only the issue of specifying the namespace for the
names in a given element instance's "markup" (its start and endtag),
here are my problems with archforms:

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!

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.

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.  

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).

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.

paul

At 16:52 1997 06 17 -0700, Tim Bray wrote:
>The namespace discussion has been bubbling away very usefully.  Perhaps
>I can summarize a bit.
>
>The solutions proposed fall into three categories:
>
>1. Extend DTD declaration syntax 
>
>2. Use Architectural Forms (maybe just calling them reserved attributes)
>
>This was argued by quite a few people, most eloquently by James Clark.
>This has the appealing characteristic that no changes whatsoever are
>required, and you can do everything with an XML parser.  It has the
>downside that if you want to avoid huge masses of attributes on everything,
>you have to start parsing DTD syntax to get the defaults.  We are 
>encountering HUGE, MASSIVE resistance to this in web-land.  When we explain 
>that it's not that hard, we are told to go away, you've given us elements 
>and attributes, we like elements and attributes, why can't we do everything 
>with elements and attributes?  I've also heard claims that the AF technique 
>falls apart in certain examples, but I haven't seen those examples yet.
>
>This a semi-upside that if we need multiple inheritance (I think we
>don't, and would prefer to avoid it if we can) it's easy to express if
>not to understand.
>
>3. Use an all-instance syntax

Received on Wednesday, 18 June 1997 14:49:57 UTC