Re: Validating Namespaces - How To

On Jun 20, 10:21pm, Henry S. Thompson wrote:
> Subject: 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.
>

I'd say I'm thinking of a namespace as similar to a module in some protramming
languages.  So binding a namespace Y to a prefix X is like saying "when you see
prefix X, then look in (module | namespace) Y for the definition.
Alternatively, when you see a prefix Z, look in the list of included (modules |
namespaces) for which one that binds to."  Inside the (module | namespace)
itself the qualifier has no meaning - it's the entity which includes it when
picks a prefix.  Prefixes are also like free variables.  If they're not bound
somewhere to point to a real entity with real definitions, there is no way to
validate.

> >  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 . . .
>
This is instead of a gi with ANY content.  It says there will be an element
here, and the element will come from whatever namespace NEAR is bound to, and
the contents will be valid for that element - it can be checked by getting the
model from the associated namespace.  It could be ENCRYPTION::, indicating some
encryption related stuff will go there, but whether that'll be RSA or DES or
whatever is left open, and can be determined by the instance -- and be
validated for the instance.

> >  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>
>
Hmmm.  Didn't think of that.  Interesting way to do inheritance.

...

> >
> >  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.
>
Good point.  If we continue with the namespace == module analogy, then each gi
must be unambiguous, so the use of 'near-gi' from the NEAR namespace would
require it to be prefixed if there were conflicting definitions.  The current
namespace would naturally take precedence.

> >
> >  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'?
>
A document using namespaces will have prefixes scattered through it.  Since (in
this model at least) prefixes are unbound variables, and there can be no
validation until they are bound, somewhere there must be text to bind them.
 This might be in the internal subset.  It might be in PIs.  Either would work
in the model.  I think the point is that the parser will see bindings, and they
should all be in agreement, whether the official DTD is read or not.

Matthew Fuchs
matt@wdi.disney.com

--

Received on Friday, 20 June 1997 20:06:44 UTC