Re: Validating Namespaces - How To

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