[
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
|
