Re: Was: [xsl] mode and moved to Namespaces
2011-04-18 00:16:38
Hi Liam,
Thank you for your interesting response.
I agree with you that, as I noted also, namespaces take some getting use
to, and typos can be ... surprising.
Let's also be clear that I have no document with 80 or so namespaces,
only stylesheets that deal with a lot of different document types.
As for translating dictionaries, what I tried to point out was not that
there was a syntactic link between namespaces and content languages,
only that conceptually natural languages, for example, were "conceptual"
namespaces, implying, or trying to imply that they may be a natural
match for (XML) namespaces, in a translation dictionary context. Yes I
can create a dictionary like
<dic>
<word>
<instance xml:lang="en" gender="m">Mr</instance>
<instance xml:lang="en" gender="f">Mrs</instance>
<instance xml:lang="fr" gender="m">M.</instance>
<instance xml:lang="fr" gender="f">Mme</instance>
...
</word>
</dic>
but, given the proper namespace declarations, I could also have it as
<dic>
<word en:instance="Mr" en-f:instance="Mrs" fr:instance="M."
fr-f:instance="Mme" ... />
...
</dic>
in both cases, source documents are using xml:lang to determine what to
pick, but:
1. while the second version could use en, en-f, fr, fr-f for values, the
first would either require a second attribute for gender or a piece of
code to split the xml:lang attribute, to match two attributes instead of
a namespace
2. in the first version, the example entry uses 17 nodes while the
second version uses 5, and more languages would increase the difference
3. as you point out, namespaces are syntactic constructs, that probably
get resolved at compile time, rather than run time
Which brings up the question that the first version is trying to get
around using namespaces for something that is conceptually
namespace-based, with some real physical, transformational, and design
costs.
I did not want to get into the discrepancies of RDF, but just tried
pointing out that stylesheets and transformation pipelines may have to
deal with multiple document types, with the associated namespaces.
OTOH, I have been thinking and addressing the RDF discrepancies and
would go beyond what you suggest, but it may be more appropriate to take
this off-list, if you care.
Having been using 80 namespaces in a stylesheet, I quite realize that
there are no "8 namespaces" limit. It was Andrew, and Gerrit
indirectly, that suggested that 8 namespaces could be a reasonable
maximum for a stylesheet. As well, both Michael and Gerrit pointed out
that a binary search may prove more efficient for managing namespaces,
beyond that "reasonable" maximum. I question the reasonableness of the
suggested maximum and feel that indeed, a binary namespace search would
be a useful feature.
As for namespace-based specific knowledge domain transformations, one
may have, for example, many attributes and elements, in transformation
pipeline streams, for example, that hold, let's say GML content that may
require typical parsing or transformation of some sort. So either each
transformation stylesheets has to know and match all possible attribute
and element names that may contain such data, or all these attributes
and elements are put in a common namespace and a template simply matches
the namespace, to processes all possible related items. Designwise, I
much prefer the latter, even if it implies defining a namespace for time
intervals and another for space intervals, and another for ...
As you suggest, one could also put all the target items into sub element
under some convention and systematically impose that convention,
somewhat like:
<timeinterval>
<morning>...</morning>
<after-noon>...</after-noon>
</timeinterval>
knowing that every element under <timeinterval> should be processed
according to time interval transformations (e.g. <xsl:apply-templates
select="timeinterval/*" mode="timeinterval"/>)
but, as this involves more nodes, less flexibility, and more processing,
again, it feels like a workaround and patch for not using namespaces,
when namespaces fit naturally, more efficiently, and more simply.
As for remembering the namespaces and prefixes, I would recommend:
1. define only required namespaces
2. define namespaces and prefixes carefully
3. break large stylesheets into smaller ones, typically around the
namespaces and associated application domains
4. look at the top of the stylesheet to find (and define) namespaces and
their prefixes
5. its mostly the stylesheets, the stylesheet documentation, the
stylesheet authors, and the individual domain document authors that need
to remember the namespaces that each is working with
This is still better than having to remember the dummy elements that
would have to be added otherwise, apart from the additional associated
document and transformation overhead. These special items would also
not be formally declared at the top of the stylesheets, making redundent
documentation a requirement. Note also that typos on the marking
elements could also create issues.
Again, those RDF issues, especially for semantic relevance and
coherence, have been resolved with much better grounded foundations, and
I would be happy to discuss and present on this, in a more appropriate
context.
Regards,
Andre
On Sun, 2011-04-17 at 19:30 -0400, 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.
There's no hard limit, but in general the more you use, the harder life
will get. It's up to you to remember them all... declare them... debug
errors when an XSLT template doesn't match because of a typo in a prefix
or URI...
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?
Namespaces are 100% unrelated to content language.
Use xml:lang to indicate language. You don't need a different namespace
for different content.
Should one not use RDF when using StratML, or XSD,
or Atom?
Well, it's unfortunate that the RDF people were farly clueless about XML
when they insisted on the namespace deign we have today. RDF/XML
confuses the syntactic and the semantic, the envelope and the contents.
But then, RDF/XML confused a lot of things (if Jonathan is reading,
"Mona lisa is a jpeg, and she is 700 pixels wide and hangs in the
Louvre" or one of my books had similarly crazy examples based on the
not-even-well-formed vcard examples in the rdf spec.)
<triple><r>resource 1</r><rel>relation</re><r>resource 2</r></triple>
would have done just fine, with, if needed,
<triple><r>resource 1</r><rel auth="MESH">relation</re><r>resource
2</r></triple>
to identify a naming authority.
But it's not that common for a single document to be using all those
different things. And just because the RDF community thinks everything
is a URI is no reason to start thinking everything is a namespace.
To answer your question, though, yes, people often do mix vocabularies.
Sometimes it's better to map to and from other vocabularies only at the
boundaries of your system, and to have a single, simpler language you
use internally.
Should names like "position" be in the same namespace whether it is
referring to time, or space, or both?
I don't see why not. All the namespace does is disambiguate elements
from *DIFFERENT* organizations or maintainers. If it's you that's
writing the vocabularies, you're not likely to need namespaces to avoid
conflicts with your own names. Namespaces in XML are purely syntactic.
For that matter,
<staff><position><name>Director</name><duties.... is fine too, in
context.
For XSLT you can have match="staff/position" as easily (more easily)
than you can have match="staff:position".
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?
There's no limit of 8 namespaces.
For that matter there's no 8 megabyte limit on the length of an element
name in XML. Nor 8 gigabytes.
Sure, you can do pretty neat things with stuff that's syntactically XML
but that's out well beyond the norm... sometimes if you do, though,
you'll end up fighting both tools and people. There's no hard cut-off,
and if what you're doing catches on, maybe the XML community will change
over time in this direction. So I won't say it's bad, or it's good, but
only, it's not commonly done today to have 80 or more namespaces in one
document. Once you get over half a dozen they are going to get pretty
hard for most people to remember!
Liam
--~------------------------------------------------------------------
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>
--~--
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: [xsl] mode, (continued)
- Re: [xsl] mode, Andrew Welch
- Re: [xsl] mode, Michael Kay
- Re: [xsl] mode, Andrew Welch
- Re: [xsl] mode, Imsieke, Gerrit, le-tex
- Was: [xsl] mode and moved to Namespaces, ac
- Was: [xsl] mode and moved to Namespaces, ac
- Re: Was: [xsl] mode and moved to Namespaces, Brandon Ibach
- Re: Was: [xsl] mode and moved to Namespaces, ac
- Re: Was: [xsl] mode and moved to Namespaces, ac
- Re: Was: [xsl] mode and moved to Namespaces, Liam R E Quin
- Re: Was: [xsl] mode and moved to Namespaces,
ac <=
- Re: Was: [xsl] mode and moved to Namespaces, Michael Müller-Hillebrand
- Re: Was: [xsl] mode and moved to Namespaces, ac
- Re: Was: [xsl] mode and moved to Namespaces, Michel Hendriksen
- Re: Was: [xsl] mode and moved to Namespaces, ac
- Re: Was: [xsl] mode and moved to Namespaces, Jirka Kosek
- Re: Was: [xsl] mode and moved to Namespaces, ac
- Re: Was: [xsl] mode and moved to Namespaces, Michel Hendriksen
- Re: Was: [xsl] mode and moved to Namespaces, Jirka Kosek
- Re: Was: [xsl] mode and moved to Namespaces, ac
- Re: Was: [xsl] mode and moved to Namespaces, Jirka Kosek
|
|
|