- From: Joe English <jenglish@crl.com>
- Date: Thu, 19 Jun 1997 10:56:34 -0700
- To: w3c-sgml-wg@w3.org
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