Subject: Re: [xsl] mixing it up: REST+XML Namespaces + XLST From: Eric van der Vlist <vdv@xxxxxxxxxxxx> Date: Tue, 19 Apr 2005 11:55:29 +0200 |
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 ------------------------------------------------------------------------
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] mixing it up: REST+XML Na, David Carlisle | Thread | [xsl] XSLT 2.0 or XSLT 1.0 -- which, Dimitre Novatchev |
Re: [xsl] mixing it up: REST+XML Na, David Carlisle | Date | Re: [xsl] mixing it up: REST+XML Na, James Fuller |
Month |