[
Lists Home |
Date Index |
Thread Index
]
<Quote>
Also if someone wants to come up with a new name for this namespace
usage
</Quote>
Poor ;)
Joe Chiusano
Booz | Allen | Hamilton
Strategy and Technology Consultants to the World
bry@itnisk.com wrote:
>
> 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.
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>
--
Kind Regards,
Joseph Chiusano
Associate
Booz | Allen | Hamilton
|
