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

Re: Was: mode and moved to Namespaces

Subject: Re: Was: mode and moved to Namespaces
From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>
Date: Mon, 18 Apr 2011 12:13:08 -0400
Re: Was:  mode and moved to Namespaces
Dear Andre,

On 4/17/2011 7:30 PM, ac wrote:
I am surprised that, with all these XML and XSLT gurus around the
table, using more than 8 namespaces in a stylesheet or application,
seems like such a strange, "out of bounds", thing. Am I crazy, or
missing something big, or is everyone sleeping at the wheel? What are
naspaces for? How can this be an issue? I am puzzled.

It's not an issue. It's just that in the normal use case for XSLT (admitting that there may really be no such thing), we just don't need so many of them.

Don't natural languages at least each have their own "natural"
namespace? If an application supports i18n and localization, should
it use less namespaces than the number of locale it supports? What
about translation dictionaries? Should we reinvent a different
mechanism to implement natural namespaces, rather than simply use XML
namespaces?

I'm not sure where to begin with this.


The deployment of namespaces and the management of the scoping issues
related to them is a non-trivial problem in XML applications, and an
interesting one. But until you actually offer a specific analogy or
comparison with natural languages, it's hard to say whether any would
make sense.

As others have remarked, XML offers myriad ways of distinguishing semantics not only with element and attribute types but also their combination, what we ordinarily call "context". While namespaces can conceivably be used for this purpose, I can't think off hand of any that have caught on widely ... not because they don't work well (although they might not), but because they are less "normal" given XML's ordinary document-centric conceptual model. Part of this may be simply force of habit, but it also has to do with tools, implementation and maintainability, especially for markup languages and applications intended to be used by dozens or thousands of people without much expert support.

What about the 22 "basic" namespaces that I quoted, as well as other
 basic XML namespaces? Should one not use RDF when using StratML, or
XSD, or Atom?

Should names like "position" be in the same namespace whether it is
referring to time, or space, or both? Should one not manage time if
one is managing space or vice versa?

That depends. Natural languages handle such problems situationally, through what you might call "operational context" -- combined with feedback for disambiguation. (That happens on this list routinely, as when you say X and I say "did you mean XY" and you say "no, I meant XX".) Chomsky notwithstanding, not many of the rules of natural languages seem to be hard wired: the brain seems to be more like a flash (writable) ROM. Linguists and psychologists debate over which rules and features of natural languages might have a genetic and physiological basis.


Your question seems to imply that natural languages each have their own namespace, as in "English", "French" and so forth. But linguists will certainly dispute this: the boundaries between languages are actually much more fluid than this, and are constantly being negotiated (see "feedback" above). Not only are the boundaries themselves not stable over time, but even the clarity of a boundary may change. And many (most, or all) people are multilingual, even if the only languages any single person speaks are "English" or "French".

Should artificial languages be any different? On the other hand, as I said I'm not sure what bearing this has on the question. (It is interesting though.) Most newcomers to XML find namespaces to be probably the least intuitive, most confusing and most "un-language-like" aspect of XML (possibly since they're no longer about labeling things, but about labeling the labels). That tells you something, I think.

Yet even the example you offer doesn't really use namespaces in the way you suggest they should work:

<word en:instance="Mr" en-f:instance="Mrs" fr:instance="M." fr-f:instance="Mme" ... />

In XML, the namespace qualifies the name, not the content, of the thing being named (element, attribute, PI, variable, etc.). (The content may be qualified by all kinds of things, not only the name of the node it appears on, but the names of ancestors, neighbors, etc.) But here you are not qualifying the name "instance" four different times, but rather the content of the namespace-qualified attribute.

This is as if I had

<en:title>Moby Dick; or, The White Whale</en:title>
<fr:title>Moby Dick; ou, La Baleine Blanche</fr:title>

(With apologies to those who know the whale in question is a very masculine whale, even if the noun that identifies him isn't.)

The more normal way to do this would be

<title xml:lang="en">Moby Dick; or, The White Whale</title>
<title xml:lang="fr">Moby Dick; ou, La Baleine Blanche</title>

And (to bring this back on topic) part of the reason for this is that you generally want both titles to match the same template in XSLT. (And when you don't, there are easy ways to distinguish them.)

In effect, I think the technique you offer here is trying to get around the limitation in XML that attributes cannot be qualified by attributes; hence "en:instance" and "en-f:instance" etc. But namespaces can only go so far with that -- as is indicated here by the fact that you are (sometimes) overloading the namespace with information respecting both language and morphology (here, the gender of the noun). Really what you have here is a graph structure, in which data points are being discriminated with multiple qualifiers.

Plus, there's no particular gain here from the fact that all the attributes have the same local name. Semantically (at least as given), it's identical to having

<word en="Mr" en-f="Mrs" fr="M." fr="Mme" ... />

What kind of XML data should stylesheets transform, and to what XML
data should they transform it to, so that stylesheets do not use more
than 8 namespaces?

If you don't need them, then why have them? Hundreds of examples of XSLT are available on the net to consider with only a namespace or two (or none but the XSLT namespace itself).


Why get all the power of XSLT3, functional programming, and higher
order functions, for XML, if the subject and object XML is limited to
8 namespaces, including a whole set of predefined ones reserved for
the language itself?

Who says it's limited?


My stylesheets rarely need more than three or four namespaces declared explicitly. But I couldn't begin to count the number of different namespaces I've ever used or seen used -- much less the ones I've used without ever knowing it.

Cheers, Wendell

--
======================================================================
Wendell Piez                            mailto:wapiez@xxxxxxxxxxxxxxxx
Mulberry Technologies, Inc.                http://www.mulberrytech.com
17 West Jefferson Street                    Direct Phone: 301/315-9635
Suite 207                                          Phone: 301/315-9631
Rockville, MD  20850                                 Fax: 301/315-8285
----------------------------------------------------------------------
  Mulberry Technologies: A Consultancy Specializing in SGML and XML
======================================================================

Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

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.
Email
First Name
Last Name
Company
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.