RE: Why Are Schemas Hard?

[Jeff Lowery <jlowery@scenicsoft.com>]

> Maybe tangential, but why do relational theorists 
> not have complaints with namespaces (shallow structure, 
> aliasing in the queries)?   In other words, other 
> than the flags, do the namespace/schema complaints 
> relate to the OOPness or relational bent of the 
> developer?  Are they easier or harder to use given 
> the implementation bias?  For example, backward engineering 
> a relational db, schemas are easy (so far).

I may be misunderstanding your question, but in a relational world you're
likely to be dealing with point sources of data (databases), which denote
context by origin. XML documents are not point sources (they flitter from
flower to flower), so there is no context of origin. (Of course, I
stubbornly cling to the belief that namespaces do imply a context by
practical necessity, at least until someone can convince me with a real
world counter example.)

Java packages seem the closest analogy to XML namespaces to me, but Java
packages are dependent upon location, and namespaces are not. Namespaces are
'meaningless' string of characters in a URI format. The location of a class
in a directory determines its package, but the association of element name
and XML namespace has to be made 'by hand'.

Of course, you know all this. I guess the point I am making is that because
namespaces are so abstract and loose, without attachments to (explicit)
context or location, it makes namespace qualification more prone to the
vaguaries of interpretation and usage rather than less so. There's no
real-world anchor that ties namespaces down, other than the Recommendation,
and what's left out of the Recommendation is what will cause problems. But I
wouldn't want to try my hand at it... that committee work has got to be
grueling.

S'long for now,

Jeff