[
Lists Home |
Date Index |
Thread Index
]
Alan, out of curiosity have you spent any time studying Norman Walsh's
SXPipe project?
from the first paragraph of http://norman.walsh.name/2004/06/20/sxpipe:
"SXPipe is a language for building Simple XML Pipelines and a Java
toolkit that implements it. This is hardly a new idea; a quick web
search will turn up a number of similar projects. I've written
elsewhere about why I did it and why I think pipelines are important.
This essay just describes SXPipe."
On 4/21/05, Alan Gutierrez <alan-xml-dev@engrm.com> wrote:
> * 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
>
> -----------------------------------------------------------------
> 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>
>
>
--
<M:D/>
:: M. David Peterson ::
XML & XML Transformations, C#, .NET, and Functional Languages Specialist
|
