- From: Henry S. Thompson <ht@cogsci.ed.ac.uk>
- Date: Fri, 20 Jun 97 22:21:00 BST
- To: w3c-sgml-wg@w3.org
Thanks for a useful starting point. I have a few quibbles: > Prefixes can only be on the right hand side, because the left hand > side is declaring a name in the current namespace. I think I disagree. I can construct a whole little namespace of my own, without reference to other documents, just by declaring a few element types with a qualified name. > In the content > modes, the prefix either stands alone, or prefixes an element name. > In the first case, it means that any content model from the namespace > can go there. In the second, it must be the appropriate content model > from the referenced namespace: > > <!element my-name (from-here, NEAR::, FAR::its-name)> I'm not sure I like or we need the NEAR:: semantics . . . > Attribute Definitions and Values > -------------------------------- > > We can only borrow names here. > > <!attlist my-name attr1 cdata #implied > THERE::attr2 (a | b | c) a > THERE::attr3 (THERE::a THERE::b THERE::c) THERE::c > attr4 (a | THERE::b | c) a> Why not add attributes: <!attlist THERE::foo myattr CDATA #IMPLIED> > Semantics and Validation -- the fun part > ---------------------------------------- > > The primary rule for namespace binding, as anyone who knows me can > guess, is that namespaces are all lexically bound. This means when > parsing an element in another namespace, we are in that space, and all > names are resolved as in that space. This means I don't need prefixes > for bound namespaces - if the same element is defined differently in > two spaces, then the lexical scoping will tell me which namespace the > current gi refers to, and I can use that content model. If the name > is not bound, then I will need to use a prefix. Furthermore - and > this is key - it means that if I have the DTD, the only namespace > prefixes I need to worry about are those not bound by the DTD. (Note > that if we do curry out the prefixes, we've change the rules of SGML > parsing, but not [I think] if we leave them in. I think it's neater > to take them out, as I'll do here, but that's really not necessary.) > > In a document instance, to refer to names in the outermost, default > document namespace, we prepend ::, to use something from some > other space, we prepend the appropriate prefix. Note that within a > namespace, we don't need to use prefixes for names that are > > The basic point on validation in a document, is you can stick > namespace prefixes pretty much anywhere you want, as long as two > properties are maintained: > > 1) All namespace prefixes in the document are bound to some namespace > (possibly the current one) > 2) Once all the prefixes in the document are bound, they must refer to > the same names in the same namespaces as they do in the DTD, if the > DTD were actually constructed. > > For example, let's take the content model above: > > <!element my-name (from-here, NEAR::, FAR::its-name)> > > The document may have something like one of the following: > > 1) <my-name><near-gi>....</near-gi><its-name>...</its-name></my-name> > > 2) > <my-name><NEAR::near-gi>...</NEAR::near-gi><its-name>...</its-name></my-name> In my proposal, only (2) would be allowed. What if there was a 'near-gi' in my (unmarked) namespace, and I added it to the 'my-name' content model? Someone adduced the principle a while back that namespaces should not introduce non-monotonicity, i.e., there is no way to change the interpretation of an instance by ADDING things to the DTD, which I think allowing (1) violates. > > In all cases, NEAR and FAR can be bound in either the DTD, the > document, or both. If, for example, NEAR is bound in both, then they > must agree. Otherwise the instance is invalid. I don't understand how a namespace can be bound in the instance. Or by 'document' do you mean 'internal subset'? > The big difference comes in what information would be passed to the > application. In example one, only a validating parser could pass > namespace information to the application, which it could get from the > namespace declarations in the DTD. In the second case, a > non-validating parser could pass on namespace info about NEAR (which > must be bound in the instance), but not about far, while a validating > one could do both. > ht
Received on Friday, 20 June 1997 17:21:04 UTC