[
Lists Home |
Date Index |
Thread Index
]
Hi, the following scenario does not fall under any of the scenarios described
by
Joe English in his plea for sanity (not even the psychotic),
http://lists.xml.org/archives/xml-dev/200204/msg00170.html but I consider that
there is something wrong with it and a new term for it might be created.
The scenario is of a rather large xml schema repository, dealing with a number
of different namespaces, versioning in this repository is achieved by adding in
new namespaces to one's problem domain, multiple organisations contribute to
the
schemas in any particular problem domain, so that if we have a particular
problem domain D then the additions to the repository is tracked via a
namespace
that has as part of its uri the day,month, year in which the schemas were added
to the repository:
so one might have http://D/02/17/2004 as one namespace, and
http://D/04/02/2004
as another, although both namespaces are related to our concept of D! The same
would be the case for namespaces related to concept domains of DD or C.
So I've been brought into this project and this has definitely gone on too long
to suddenly change over the logic of the repository and come up with some sort
of real versioning system in place of that which is. My theory is that a way
needs to be built on top of the current system to collapse all these multiple
namespaces into one namespace for the specific problem domain. I am open to
suggestions, in fact I am nearly begging, but currently what I am thinking is
that an overarcing namespace D will be defined and that a rddl document should
lie at any overarcing namespace in this repository system, the rddl document
would be used by people needing to access the repository to access the
resources
for collapsing whatever are the current namespaces in the problem domain.
Also if anyone has commentaries on the current structure please send them to me
as I can incorporate them into an argument for fixing the problem(as long as
it's not just "wow, you're screwed").
My own opinions of why the structure needs to be changed are rather prosaic, the
addition of numerous namespaces addressing the same problem domain means that it
will be difficult for developers to build solutions working with xml instances
containing markup referencing these always increasing namespaces, given that it
will be likely that instances containing elements in namespace
http://D/02/17/2004 will also need to contain elements in namespace
http://D/.....->x , perhaps there will be lots of code that references
*[starts-with(namespace-uri(),'http://D/')]? :(
Because of the design of the schemas also I worry that processing could come to
be a problem for solutions if this architecture was followed for a few years
longer.
Also if someone wants to come up with a new name for this namespace usage, and a
reason for the naming, help bring a smile to my agonized face.
|
