[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: 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 !

• Follow-Ups:
  • Re: XML aggregation question?
    • From: Florent Georges

• References:
  • Re: XML aggregation question?
    • From: Florent Georges