On 29/11/2007, G. Ken Holman <gkholman(_at_)cranesoftwrights(_dot_)com> wrote:
If I may cite where making this distinction is very important:
standards development. I'm working on code-list-related
specifications and the namespace distinction of foreign namespaces is
critically important to validate those standardized constructs with
adopted community-wide semantics, while distinguishing embedded
documentation constructs that are important to individual users.
If one user chooses XHTML to document their XML code list
representation and another user chooses DocBook and yet another user
uses DITA, all three users can agree on the community-standard
structural constraints of the standardized vocabulary without having
their respective vocabularies interfere.
Sounds fine (if I've read that correctly... it's a bit difficult to
parse on the first go) but you could just use the hierarchical nature
of XML to signify what's what (wrap each type in an element), if for
example there were two types that weren't in a namespace.
I feel namespaces are unjustly given a bad rap and that they play a
critically-important role in information design.
Really - critically important?
I agree with you Andrew that using a globally-unique naming
convention for a closed vocabulary (as in one used by a closed
community of users where everything is mandated under central
control) can be overkill, but I see no harm and only benefit in
distinguishing using namespaces the documentary constructs
unimportant to the semantics of the information being acted on.
Sorry Ken - parse failure on that whopper of a sentence! I think I
get the semantics even if the syntax causes problems... :)
I've never come across the aggregation of multiple XML sources where
I've thought "good job they are in different namespaces otherwise I'd
be stuck here"... but I have come across many single XML documents
with several namespaces which do nothing more than make processing
that XML needlessly more complicated.
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>