sounds right. One point of view might be that namespaces are
used where aggregation by namespaces is unavoidable, say
is compounding languages into XHTML. But just to support
use of globals, that has the feel of too much factoring. After
it's all Just ASCII, right? ;-)
Again, like those overwrought parameterized DTDs, I think
clarity tradeoff might be better. I do wonder if it might
been better not to try to combine aspects of object types
relational techniques with some hidden objective of
producing a contract best filled by an object-oriented
well... just another permathread.
address the problem of having multiple layers of abstraction and
of global elements that forces one to use namespaces? GJXDM
wrestling with this one.
My basic use case was a workflow in which an element or
attribute that can't possibly exist at step 1 (e.g. an "arrived" date-time stamp on data sent from a supplier) is required at step 1 + x. We
don't want to just declare it as being optional up and down the line; we
want a validation process after step x to flag files missing this data.
The approach is to declare everything you'll ever need
and identify where you need it in the central mother schema and then extract
what you need for each step using the stylesheet. It should work in some
cases in which the "views" do not necessarily describe the states of
data in a sequential process, but that was the problem I was focused on.
(We've got a lot of XML data moving through a lot of processes here.) I didn't try pushing it into a more generalized version of a "view"
implementation, so, I'm not sure about dealing with the multiple layers of