Re: Update on namespaces

At 10:56 1997 06 19 -0700, Joe English wrote:

>I think you misunderstand how AFs work:

You may very well be right!

But let me try to add a few comments embedded below that will either
serve to explain what I meant or further expose my confusion.

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

My understanding is that the way you know the archform for any element
is to inspect it's attribute specification list for an attribute that
gives its archform and take that attribute's value as the archform
indicator.  I know that attributes can be given default/fixed values 
in a DTD, but if you don't have a DTD, then the only way to associate
an archform with an element instance is for it to have an explicit
assigment to the archform-specifying attribute, and this attribute
is, effectively a "namespace-specifying attribute" in my book, hence
I don't yet see the refutation of my comment.  Try me again if I'm
misunderstanding things.

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

I don't really understand this, and it sounds like your example
supports my position.  If the way I specify namespaces is by associating
an archform with an element via an assignment to one of that element's
attributes, how can I specify that another one of the attribute value 
specifications in that attribute specification list comes from a different 
namespace?  If the answer is to put TEIlite: in front of it, that's just 
the kind of thing I'm envisioning, but that's not restricting yourself to 
using archforms as I understand them.  If archforms includes "TEIlite:" 
sorts of syntax, I'm quite interested in learning more about that.

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

That's quite possible.

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

Then in what way did I misundertand how AF's work above?

>
>>not its basic parsing.
>
>They don't.

But namespaces do, so I don't see how archforms can solve the
namespace issue.

Received on Thursday, 19 June 1997 14:36:28 UTC