[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: URI Design
* Philippe Poulard <Philippe.Poulard@s...> [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@e... - http://engrm.com/blogometer/index.html - http://engrm.com/blogometer/rss.2.0.xml
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|