[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: URI Design

• To: Alan Gutierrez <alan-xml-dev@e...>
• Subject: Re: URI Design
• From: Philippe Poulard <Philippe.Poulard@s...>
• Date: Thu, 21 Apr 2005 18:27:44 +0200
• Cc: xml-dev@l...
• In-reply-to: <20050421152930.GE29144@m...>
• References: <20050421152930.GE29144@m...>
• User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041220

hi,

why don't you use XPath ?

I'm currently working on an XML view of HTTP, that is a pale copy of 
what Java provides with servlets :)

This is a part of the Active Tags framework, here :
http://disc.inria.fr/perso/philippe.poulard/xml/active-tags/
and this HTTP view is the web module, here :
http://disc.inria.fr/perso/philippe.poulard/xml/active-tags/web/web.html

Real example :
we want to process an URL like this :
http://www.foo.com/projet.html?projet=TheBigProject
we make a connexion to an XML native database (Xyleme Zone Server) 
through XML:DB API with a request that takes a parameter that returns an 
XML document transformed with XSLT :

<web:mapping method="GET" url-match=".*/projet\.html?projet=.+">
       <xnd:request
             name="theProject"
             connect="{ $connect }"
             type="XyQL"
             output-type="DOM"
             query='
                 SELECT projet
                 FROM fiches_projets IN FichesProjets,
                     projet IN fiches_projets//projet
                 WHERE projet/nom_projet CONTAINS "{ value( 
$web:request/projet ) }" ;'
       />
       <xcl:transform
             source="{ $theProject }"
             stylesheet="{ $projet.fr.xslt }"
             output-file="{ $web:output-stream }"
       />
</web:mapping>

what you can see is that most HTTP resources are exposed as XPath 
variables : { value( $web:request/projet ) } get the value of the 
parameter "projet"

the XPath variables are XML-friendly objects, that is to say that they 
can be crossed by XPath expressions like this :
$web:application/@web:init-param/@myInitParam
here you can see that the attribute "web:init-param" is not an XML 
attribute, but an object that contains itself other attributes

the implementation works fine, but some points have to be fixed :
-the web module is not yet completed
-SAX is not yet supported

the advantages :
-you can use an existing XPath engine
-you take benefits of namespaces to avoid collisions (have a look at the 
Web module, I mix predefined web:xxx attributes with user defined 
attributes that can't be set with a namespace so there is no conflict)

================

anyway, in your example, you could use :
{ $web:request/e-mail-address[ 1 ] }

however, if you still want to use URIs, i suggest you to add a third / 
in your model, because what you handle (I think) are PATHS, and if you 
omit a / you will have an AUTHORITY (userinfo@server:port) and 
(eventually) a PATH :
request:///document/
request:///content/
request:///field/e-mail-address/1
if you parse these URIs with java.net.URI, you won't have an AUTHORITY 
with them, but you will get one with yours

see RFC-about-URIs for more informations

Alan Gutierrez wrote:
>     I'm working on my XML pipeline engine, Relay. I'm using special
>     URIs to view information as documents. I'm creating a servlet,
>     for example, that explodes the HttpServletRequest into a
>     document, so I can bite into it with XSLT.
> 
>     <request>
>       <path-info>/foo/bar</path-info>
>       <server-name>engrm.com</server-name>
>       <content-type>application/x-www-form-urlencoded</content-type>
>       <content-uri>request://content/</content-uri>
>     </request>
> 
>     The above document is available from the URI:
> 
>     request://document/
> 
>     As you can see, I get the input as a stream using:
> 
>     request://content/
> 
>     I parse the content of the post in a Relay, and it makes each
>     form field avaialable as a stream, in case one of the fields is
>     really a hidden field with an JavaScript generated XML document in it.
> 
>     Or, else, I can run a textarea through HTML Tidy, to permit mild
>     markup in a comments box.
> 
>     That URI looks like:
> 
>     request://field/e-mail-address/1
> 
>     Which will return the first field named e-mail-address as a
>     stream.
> 
>     What do you all think? Am I designing these URIs correctly?
> 
>     Should I bother making them heirarcical? Or should I simply
>     create my own interpreation of the scheme specific part?
> 
>     request:document
>     request:content
>     request:field:e-mail-address[1]
> 
>     Thanks.
> 
> --
> Alan Gutierrez - alan@e...
>     - http://engrm.com/blogometer/index.html
>     - http://engrm.com/blogometer/rss.2.0.xml
> 
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
> 
> The list archives are at http://lists.xml.org/archives/xml-dev/
> 
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>
> 


-- 
Cordialement,

            ///
           (. .)
  -----ooO--(_)--Ooo-----
|   Philippe Poulard    |
  -----------------------

• Follow-Ups:
  • Re: URI Design
    • From: Alan Gutierrez <alan-xml-dev@e...>

• References:
  • URI Design
    • From: Alan Gutierrez <alan-xml-dev@e...>

• Prev by Date: Re: A Stakeholder's Response: XQuery APIs for Middle Tier and Clients
• Next by Date: Re: URI Design
• Previous by thread: Re: URI Design
• Next by thread: Re: URI Design
• Index(es):
  • Date
  • Thread