Re: mixing it up: REST+XML Namespaces + XLST

Hi David,

On mar, 2005-04-19 at 09:19 +0000, M. David Peterson wrote:
> 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. 

OTH, but by doing that, you're "hard wiring" the method to the physical
location addresses by the namespace URI.

> What you then lose of course is the ability for this same set of data
> to be easily processed via another REST-based method. 

Exactly. If you need to maintain both a development and a production
environment, you'll have to either use different namespaces or add an
indirection mechanism.

> 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. 

Isn't that more complex than the problem this hack was supposed to
solve?

> 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?

The main reason is, as you've mentioned above, flexibility.

If you use:

<company lnk="http://www.example.org/app/tables/company"/>

you leave to the application the possibility to return instead:

<company lnk="http://test.example.org/app/tables/company"/>

If you were doing the same thing with a namespace URIs, you'd have to
use different sets of stylesheets (and of applications in general) to
process results coming from your test and production systems.

> > 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.

It's not enough to drawback this solution by itself, but since the
initial motivation seemed to be a simplification, using namespaces
didn't seem to go in the right direction :-) ...

> > 
> > 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?

Sure. As other posters on this list, I just don't buy the (ugly IMO)
PSVI vision to which XSLT 2.0 belongs and, for that reason, I consider
XSLT 1.0 both simpler and more elegant :) ...

Eric 

> Cheers :)
> 
-- 
Weblog:
                 http://eric.van-der-vlist.com/blog?t=category&a=English
------------------------------------------------------------------------
Eric van der Vlist       http://xmlfr.org            http://dyomedea.com
(ISO) RELAX NG   ISBN:0-596-00421-4 http://oreilly.com/catalog/relax
(W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema
------------------------------------------------------------------------