OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] URI Design

[ Lists Home | Date Index | Thread Index ]

* Philippe Poulard <Philippe.Poulard@sophia.inria.fr> [2005-04-21 12:28]:
> 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

    Phillipe

    Yes. I agree. That is slated, fetching content as streams using
    XPath or XInclude would generalize this application further. 

    I do know that document, content, and field, are going to be
    part of the authority. It seemed to make sense to me, to try to
    use one of the fields. Perhaps it makes more sense as part of
    the path. It gets ugly, though, and there is no real heiararchy,
    so perhaps the scheme specific part should be scheme specific.

    Using XSLT or XPath to Fetch Streams

    I'm stringing together XML processes, mine is an XML pipelinging
    engine that creates a pipeline, on the fly, from an XML
    specification document. It's a pipeline engine that eats XML, so
    logic is delegated to XSLT, specifically Saxon's implementation
    of XSLT 2.0. Very powerful.
    
    As I noted, I would like to create a transform one could stick
    in a pipeline that selects content using an XPath statement, and
    then streams it as text. Input is SAX, output is a byte stream.

    It could then be parsed, or processed in some other way. This
    would be a grand abstraction, you can turn any bit of a document
    into a stream and start processing from there. 

    About Treating Fields as URIs

    However, this break down that I metion for HTTP post was
    inspired by the desire to support XMLHttpRequest, multipart
    forms with uploads, and standard urlencoded forms usign a common
    abstraction.
    
    A common abstraction would be to simply treat the POST input as
    a stream and run it through the correct parser, an XML parser, a
    multipart mime parser, or the simpilest, a form decoder. The
    rest of your form processing pipeline could be the same, and
    content could come from AJAX, or HTML forms. It would be a
    matter of prepending the correct parser to the pipeline.

    The form document would include the value, in place, so you
    could get at it with XPath. Except for multipart forms with file
    uploads, where the file upload fields would include mime-type,
    content-length, and URI. The URI would point to a stream, and
    one could use the stream to feed another pipeline.
    
    With that plan, I figured it would be simple enough to give a
    stream view of any field, so I'll make that URI avaiable for all
    fields. For an file upload containing a JPG, however, the URI is
    the only reasonable way to process the data.

    So, yes, XPath access is there, and I'm looking at dealing with
    streams that are not XML, so I need a URI representation. I'll
    attempt to support both views.

    URI Design

    I'm thinking that my URIs are probably not heirarchical.

--
Alan Gutierrez - alan@engrm.com
    - http://engrm.com/blogometer/index.html
    - http://engrm.com/blogometer/rss.2.0.xml




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS