[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
Re: [xml-dev] XML aggregation question?
- From: Philippe Poulard <Philippe.Poulard@xxxxxxxxxxxxxxx>
- To: Florent Georges <darkman_spam@xxxxxxxx>
- Date: Mon, 28 Aug 2006 17:53:27 +0200
Florent Georges wrote:
> Philippe Poulard wrote:
>
> [ Au fait, salut Philippe ;-) ]
Salut Florent ;)
>
>
>>>>file('file:///c:/xslts_1_0_0/TestInputs')//*[@extension='xsl']
>>>>or whatever à la XPath ?
>
>
>>> Saxon's syntax is an "à la XPath" syntax, isn't it?
>
>
>>'file:///c:/xslts_1_0_0/TestInputs?select=*.xsl;recurse=yes'
>
>
>>this part is not, comparing to what I proposed
>
>
> Mmh. Saxon uses a standard XPath function that takes a URI as
> parameter. I don't see what is not "à la XPath". You use an unknown
> function. They smell equally XPath IMHO.
Read again my first post : the purpose is neither the name of the
function nor about how to get the content of the file
It is rather an open topic on "browsing non-XML objects with XPath like
if they were XML" for XML-oriented Programming
As a file system is a tree structure, it is a good candidate when one
apply //* on it ; if some of its properties would be exposed as
attributes, one would expect to access to them with @XXX
This is the way adopted in Active Tags for file systems and some other
objects ; in this framework, the name of the function is io:file() which
belongs to the I/O module, and an x-file object exposes about 15 of its
properties as attributes, which allows to write XPath expressions like
this :
io:file('file:///path/to/dir')//*[@io:is-file][@io:extension='xml']
(this expression selects all the files which extension is 'xml' under
the tree located within '/path/to/dir')
With this collection of files, we can parse, transform, etc
Now, some people had designed their own syntax...
-Saxon's syntax :
collection('file:///c:/xslts_1_0_0/TestInputs?select=*.xsl;recurse=yes')
-Ant's syntax :
<fileset dir="file:///c:/xslts_1_0_0/TestInputs" includes="**/*.xsl"/>
...to perform the same thing (selecting a set of files)
If they had to deal with something else than a file system, would they
invent yet another syntax ?
My answer is : "why not using XPath everywhere in XML applications ?"
Pros :
-a single syntax
-a well-known syntax
-an efficient syntax
Cons :
-???
>
> BTW, how do you specify to recurse or not?
//* recurse
/* do not recurse
It's XPath
And to validate or not?
What means "validating a file" ?
> And how do you get the actual content of the files? Are they
> encapsulated directly in the result of file() (I hope they are not), or
> do you need a second function (something like open-file())?
Everything can be considered here ; have a look at RefleX : there are
many examples where files are selected and processed :
http://reflex.gforge.inria.fr/
>
> But your approach is interesting, IMHO, with optional arguments to
> specify switches, and assuming it returns only file infos, not actual
> content.
Of course, the content is returned only when it is required
>
> Maybe an idea to start an EXPath library, defining extension
> functions to be implemented by various XPath, XQuery and/or XSLT
> engines?
In my implementation, the functions available in various Active Tags
modules (understand : library) are derived from the popular Jaxen "Java
XPath Engine"
The Active Tags suite intends to use external tools like XSLT or XQuery
rather than being available from XSLT or XQuery, but if the proposition
like those mentioned above about file systems were widely adopted, a
bridge could be made to make it accessible.
>
> Regards,
>
> --drkm
>
--
Cordialement,
///
(. .)
--------ooO--(_)--Ooo--------
| Philippe Poulard |
-----------------------------
http://reflex.gforge.inria.fr/
Have the RefleX !
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]