Pawson, David wrote:
-----Original Message-----
From: James Fuller
performing a GET on top level URL
http://www.example.org/app/tables returns
<tables>
<user xmlns="http://www.example.org/app/tables/user"/>
<company xmlns="http://www.example.org/app/tables/company"/>
<products xmlns="http://www.example.org/app/tables/products"/>
</tables>
note, I have bastardized REST by eschewing with xlink:href
(was just transforming them into other things in any event)
and defining namespaces.
Why mess with dereferencing namespaces Jim? Why not use your own syntax?
<company lnk="http://www.example.org/app/tables/company"/>
Works just as well, and doesn't upset TAG people!
hehe, actually got tired of transforming xlink:href...and said to myself
well here is an empty spot...
so I now find myself doing things like defining namespaces
for use in XSLT (though we dont have to explicitly define
them, necc);
then with the various fn:namespace functions e.g.
fn:namespace-uri,fn:namespace-uri-for-prefix,fn:namespace-ur
i-from-QName
I can now infer access these resources with document() calls.
Is this the reason for using namespaces?
(or should that be misusing?)
<xsl:variable name="company"
select="document(fn:namespace-uri(.))"/>
With every document() call I recieve xml with relevent
namespaces which point to their REST implementation...it
feels very state like to me, being passed a namespace which
contains its REST URI implementation....would like to hear
if anyone else is using XML namespace to their own ends ?
No, but I'd not thought of using namespaces simply to make use
of XSLT 2.0 functionality :-)
hehe, its XPATH functionality which makes it a bit more generic
Does using a @lnk make you feel any better about it?
i have done this with xlink:href for a year and half now, all I did was
transform xlink:href......never used any xlink engine etc....never will...
Doesn't seem very stateful to me Jim, whichever syntax is used?
well with every document() call I am guarenteed to have a few namespaces
which point to their resource, including the one for the resource
itself, so for every HTTP GET I get resource location for free, not to
mention that with new xml I could get another set of namespaces that all
point to their implementations.
I wont make an arguement for such a bastard child...but it does save a
few cycles and its usage within XSLT is pretty elegant.
ta, Jim Fuller
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--