Subject: Re: [xsl] mixing it up: REST+XML Namespaces + XLST From: "M. David Peterson" <m.david.x2x2x@xxxxxxxxx> Date: Tue, 19 Apr 2005 10:35:52 -0600 |
These are all great point Eric :) Thanks for taking the time to respond... definitely gives me some more to consider as I choose direction on my own projects that have utilized some of which Jim is suggesting. Cheers :) On 4/19/05, Eric van der Vlist <vdv@xxxxxxxxxxxx> wrote: > 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 > ------------------------------------------------------------------------ > > -- <M:D/> :: M. David Peterson :: XML & XML Transformations, C#, .NET, and Functional Languages Specialist
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] XSLT 2.0 or XSLT 1.0 -- w, Eric van der Vlist | Thread | RE: [xsl] XSLT 2.0 or XSLT 1.0 -- w, Pawson, David |
Re: [xsl] Total number of pages wit, Nadia . Swaby | Date | Re: [xsl] xsl:for-each...iteration , JBryant |
Month |