RE: infinite depth to namespaces

["Arnold, Curt" <Curt.Arnold@hyprotech.com>]

> Right.  Which is why, if you're going to use local elements 
> in a schema, you should make them unqualified, as that works 
> best with existing software. See my response to Rick.

I think it depends whether the element is defined locally to enforce a context specific constraint or if the element is defined locally since it has no meaning (or possibly ambiguous meaning) outside
of its context.

If, for example, I want to constrain a person element so that it must have at least one child if it appears a <parents> element but the element can appear outside of that outside of that context
without that constraint, I would suggest the best way to encode that constraint within the current capabilities of XML schema would be to declare a namespace qualified global element without the
constraint and a local namespace qualified element with the constraint in the appropriate context.

If <person> has the same meaning and general structure in all uses in a schema but only differs due to constraints due to context, the it is better to have them all qualified so that XSLT and other
technologies can recognize them as the same concept, instead of totally unrelated concepts.

> This also shows that best practices need to evolve.  While 
> "put everything in a namespace" was reasonable best practice 
> before the arrival of XSDL, the concretization of a notion of 
> "local elements" (I hesitate to call it
> "formalization") - just as the Namespaces rec concretized the 
> notion of "global attribute", which hadn't existed 
> syntactically before, although people used them - can change 
> what best practices can be.  And best practices for local 
> elements is unqualified.
> 
> Matthew