Re: [xsl] mixing it up: REST+XML Namespaces + XLST

["M. David Peterson" <m.david.x2x2x@xxxxxxxxx>]

Hi Eric,

On 4/19/05, Eric van der Vlist <vdv@xxxxxxxxxxxx> wrote:

> Hmmm... I must be missing something, but I don't see how
> "document(fn:namespace-uri(.))" saves cycles compared to
> "document(@lnk)"!

I agree, cycles would actually be increased by at least one call to
the namespace-uri function to pluck the proper namespace to be used
via the document function.  However, there is a benefit of using
namespaces in this regard: order and maintainability of the code base
come to mind as does the fact that by binding a sequence to a
namespace you have built into your codebase a simple way of ensuring
that the associated data is always processed by the correct method.
What you then lose of course is the ability for this same set of data
to be easily processed via another REST-based method.  For this you
would obviously be required to create an override method that would
check for certain conditions and if present, reroute the processing of
this data to whichever method is deemed appropriate.  With this in
mind you would then add another sequence of cycles which is an obvious
performance drain... by how much? Obviously theres no way to know that
without code and a knowledge of which processor will be handling the
transformation process.  But I can't say that without this info theres
no way to decide whether this is still a viable and reasonable
solution.  I still believe that the usage of namespaces adds enough of
a boost to the pro side that the con side would probably require some
pretty hefty additions to make the argument against this method
justifiable.

but I do respect your opinions on this and am curious to hear more as
to why you would or would not utilize namespaces as a good and proper
way of binding data to the correct REST-based processing method...
Thoughts?

>
> Furthermore, your trick requires that you use namespaces in your
> instance documents which you might have been able to avoid without it
> and these namespaces do add many cycles (for instance imposing that you
> use prefixes in all your XPath expressions).

Again...  would like to hear more about why you feel that the added
complexity of namespace usage within your instance data would be
enough of a drawback to play it down as an unreasonable solution.

>
> Isn't it very subjective :-) ?
>
> Personally, I wouldn't call using XSLT 2.0 "elegant" at all !

It is subjective as is the context in which the phrase is used.
Setting personal opinions aside, if considering the comparison is
between a 1.0 codebase and a 2.0 codebase I would argue that XPath 2.0
alone is enough to at least give "elegance" a fighting chance of being
part of the official "usable" descriptors for an XSLT 2.0 codebase.
But elegance is never something that XSLT should really ever be
focused on as a specification criteria.  The fact that it is XML-based
opens the doors for tool vendors to make the elegance argument much
more realistic.  Thats not to say that if the opportunity for
performance, reliability, extensibilty, and elegance can all make it
into the mix without the first three having to "give in" to the
demands that elegance brings to the table that elegance should not be
paid its dues.  But if the first three must suffer just to gain a more
elegant appeal then I personally would grab elegance by its prissy
little ear and find him a rock to kick on his way back to the XQuery
working group -- they seem to like be worried more about elegance and
less about structure which is fine -- theres a place for everyone at
the table of the WWW, right?

Cheers :)

--
<M:D/>

M. David Peterson
:: http://www.xsltblog.com ::