[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Another Example [Was: Namespaces]

Subject: Re: Another Example [Was: Namespaces]
From: ac <ac@xxxxxxxxxxxxx>
Date: Wed, 20 Apr 2011 14:49:42 -0400
Re:  Another Example [Was: Namespaces]
Hi Geert,

As you can understand, I especially appreciate your contribution.

However you look at it, namespace numbers tend to go up, especially with application scope, but also as more and more XML users define them, especially for standards, but also for libraries. More so, more and more knowledge domains need to be addressed and often require new distinguishing namespaces. Add to this the "odd ball" use case, where, for example, memory usage can be an issue and namespaces can help, and you are starting to have a forever increasing set of namespaces in stylesheets.

As Michael noted, rightfully backed by Gerrit, a binary rather than linear search, may be a valuable optimization, that is hopefully not too expensive.

Going a step further, it is not uncommon for namespaces, although they are currently flat, in practice, to be logically hierarchical. Let's just take the XSL and/or RDF standards families, as common examples, where each includes a set of related namespaces (e.g. RDF + RDFS, XSL + XDT + XSI + XSD), with hierarchical namespaces (and namespace URIs), one could possibly simply declare a common parent namespace if one needs to use a few of the children namespaces, rather than have to declare and use each child namespace, for example. Another consideration may be about combining namespaces, as reflected by the prefix usage example: fr:fem:plur:xxxx.

I am not saying that this is how it ought to be, I am only trying to suggest some possible avenues to improve and extend namespaces, while providing better support to help face their proliferation.

As Abel rightfully noted before, there is a lot of experience around this list and I am sure that more and better suggestions can be provided. From my humble experience with namespaces, I see their number, use cases, and applications growing, I can feel their power and potential, and I can see their conceptual and logical relevance, Hence my feeble and clumsy tries to bring up the issue.

Thank you for your understanding contribution.


Hi all, ac in particular,

Reading the namespace thread, I felt it worthwhile throwing in an
example we are working on at this end.

We are currently building a warehouse for a large international
publishing house.
We need to bring in stuff from different localized companies all
having their own vocabularies.
Although we tried to make a generalised vocabulary for the metadata,
we needed to allow local extensions,
and for avoiding conflicts between the element names, we gave each
local company its own namespace for the extension
So, we are having a couple of our own namespaces and then some 10
easily for the local extensions (number still growing)
In my opinion this is what namespaces are meant for... so legitimate
use so far

At the publishing end we are pushing to various portal solutions,
including stuff such as MathML, SVG, XHTML,
plus for avoiding naming conflicts again, some extensions based on the
document type, again with different namespaces

Somewhere in the middle we are using RDF, SKOS, ... do I need to make
a picture? Another 5 namespaces easily

I am not going to count exactly now what I have so far in my stylesheets,
but I bet I have over 30 in them, closer to 40 than to 30 I am afraid.

I have cut some corners in the story, so please don't go picking on
the details.
I am pretty convinced that having 30 or more namespaces in my stylesheet,
is not something that makes me extremely happy,
but is something that is very hard to avoid in the huge scope of these

Just my 2cts


Current Thread


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.