Re: Update on namespaces

Paul Grosso <paul@arbortext.com> wrote:

> 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!

I don't follow this.

With AFs, the element's GI belongs to the namespace of the document's
own DTD.  There is no "namespace-specifying attribute"; rather,
there is a single attribute for each base architecture, whose value
is the name of a GI from that architecture.  There's no potential
for ambiguity if you're just dealing with GIs.

[ If you want an element to use attributes from a base architecture, then
  there is a potential for nameclashes, either between two different
  base architectures or between a base architecture and the derived
  DTD.  The AFDR has one more piece of machinery to handle this
  situation, the "architectural attribute renamer" attribute. ]


> 2.  by using archforms, you have no way to allow different names in
>     a start tag to come from different namespaces.

On the contrary, this is _precisely_ what the AFDR is designed to do!
(Except that it uses the word "architecture" instead of "namespace".)
In fact most of the AFDR machinery is devoted to figuring out
which attribute specifications belong to which base architectures.
Fortunately most of the machinery is only needed in the case
of a nameclash, or if the DTD designer wants to allow minimization.


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

Not at all.  It may take more black magic (the ArcNamR attribute),
but again, this is only necessary in the case of a nameclash between
attributes.

<ASIDE HTML="P" TEIlite="NOTE" TEILite:type="aside" TEIlite:lang="EN-US">
Hmm... perhaps if we require a 'namespaceid:' prefix -- as an
application convention for base architectures rather than giving it
semantic importance as has been proposed -- it might give us the best
of both worlds: compatibility with the AFDR for validatibility and
theoretical underpinnings, and a DPH-friendly syntax.
</ASIDE>

> 3.  [...]
>    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.

I think you misunderstand how AFs work:

> Said another way, I think archforms should only
>     affect the application-level semantic processing of a document,

They do.

>not its basic parsing.

They don't.

They do allow additional validation constraints to be expressed and
enforced, but they do not change the parsing process.


I'm beginning to think that neither AFs nor namespace prefixes need
to be added to the XML spec.  The AFDR exists and is usable on its
own; those of us who want to use it in XML applications can do so.
Likewise namespace prefixes; those who want to put a disambiguating
prefix in front of GIs and attribute names can do so in their
applications.  Neither approach needs explicit support from
general-purpsose XML parsers, so neither one needs to be enshrined in
the XML spec,


--Joe English

  jenglish@crl.com

Received on Thursday, 19 June 1997 13:59:54 UTC