This is GREAT Jim! I am doing a TON of work with this type of thing
right now, near identical in many ways to the way you are doing
things. It is my belief that namespaces are the single most important
part of integrated XML software development, but that obviously no
revelation. Coupled with mime types I believe they are the foundation
of what I believe to be the next "trend" in weblication software
development, that of the merging together of the WWW with the desktop,
coupled together via a continued push towards a grid-like
infrastructure in which the line between client and server becomes
completely transparent and in many ways will not even exist at all.
But again, nothing revealing in any of this... Obviously there are a
lot of us who are gravitating towards all of this and have been for
quite some time. But it is certainly exciting and I am definitely
looking forward to being a part of all of this!
Cheers :)
<M:D/>
On 4/18/05, James Fuller <jim(_dot_)fuller(_at_)ruminate(_dot_)co(_dot_)uk>
wrote:
let me preface the following that I have no burning desire to *put*
something that means something within an XML namespace URI...though was
wondering of any variations on the following theme exist out there in
the wild.
for this simple illustration, I will just talk about HTTP GET and none
of the other CRUD operations that map to REST
take for example take a simple REST interface to a database with a few
tables;
http://www.example.org/app/tables/company
http://www.example.org/app/tables/user
http://www.example.org/app/tables/products
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.
performing GET on these URL's will return XML with a list of records,
<records>
<company xmlns="http://www.example.org/app/tables/company";>1</company>
</records>
sending a GET for http://www.example.org/app/tables/company/1/ would in
turn return XML data about the com
<row xmlns="http://www.example.org/app/tables/company"; xml:ID="1">
<uid>1</uid>
<name>My Company</name>
<phone>wou 55</phone>
<email>jim(_dot_)fuller(_at_)ruminate(_dot_)co(_dot_)uk</email>
</row>
note: I have used xml:ID to identify because I have written a bit of
code to handle such things.
so I now find myself doing things like defining namespaces for use in
XSLT (though we dont have to explicitly define them, necc);
xmlns:company="http://www.example.org/app/tables/company";
xmlns:products="http://www.example.org/app/tables/products";
xmlns:user="http://www.example.org/app/tables/user";
then with the various fn:namespace functions e.g.
fn:namespace-uri,fn:namespace-uri-for-prefix,fn:namespace-uri-from-QName
I can now infer access these resources with document() calls.
<xsl:variable name="company" select="document(fn:namespace-uri(.))"/>
by being able to consume the record lists its easy to create detail
level document() calls...also if your data has regular id
sequences...its now easy with ranges and such to just append the id
number to document() call.
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 ?
cheers, 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>
--~--
--
<M:D/>
:: M. David Peterson ::
XML & XML Transformations, C#, .NET, and Functional Languages Specialist
--~------------------------------------------------------------------
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>
--~--