That
sounds right. One point of view might be that namespaces are
best
used where aggregation by namespaces is unavoidable, say
one
is compounding languages into XHTML. But just to support
the
use of globals, that has the feel of too much factoring. After
all,
it's all Just ASCII, right? ;-)
Again, like those overwrought parameterized DTDs, I think
a
clarity tradeoff might be better. I do wonder if it might
have
been better not to try to combine aspects of object types
AND
relational techniques with some hidden objective of
producing a contract best filled by an object-oriented
database.
Ah
well... just another permathread.
len
>Did you
address the problem of having multiple layers of abstraction and
>the use
of global elements that forces one to use namespaces? GJXDM
>is
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
abstraction.
Bob
