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

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