- From: David A. Lee <dlee@calldei.com>
- Date: Thu, 23 Jul 2009 09:30:58 -0400
- To: Toman_Vojtech@emc.com
- CC: xproc-dev@w3.org
- Message-ID: <4A686612.5020408@calldei.com>
Ok that makes more sense.
If I were to vote :) ... I'd vote for exactly the way it is.
Unless you set the system ID then of course it should be relative to
that ...
Here's my rationale.
The pipeline is the "root of all things". Thus I think it makes most
sense for inputs (and outputs) to be relative to the pipeline. This
minimizes dependencies on the environment.
Particularly for Java API's ... as the "current directory" is a less
then ideal concept in java.
This also aids in integrating if documents specified *within the
pipeline* are relative, and presumably they are relative to the
pipeline, not the CWD.
That lets you treat both input (to the pipeline) and embedded documents
the same way.
Now if you want the opposite behavior, explicitly either doing the path
resolution yourself, or setting the System ID on either the Pipeline or
the documents should take precedence.
I suggest your last comment is the most telling
> > On the other hand, if your pipeline is at
http://foo/pipelines/pipeline.xpl and you pass "../data/doc.xml" as the
source URI, the engine will automatically load it from
http://foo/data/doc.xml
As I've gotten more used to the concept of languages operating on the
"world of the web" instead of "the world of the filesystem" I find this
model more compelling, even though it does add confusion.
A obvious example is *output documents* ... In xmlsh I've been trying to
allow any URI as the CWD but I haven't been successful. OK I failed
miserably and abandoned the idea for a while.
Thats because there is no universal way to do either "ls" or ">file"
using URI's. Sure "PUT" is *supposed* to work but how many sites
actually support it ? and what about other schemes besides http:// ?
and there is no good way to do "ls" on a URI that isnt a file.
There's tons of hacks but no really good universal way of getting the
"contents of a URI treated as a directory".
So trying to treat a URI as a CWD, while intellectually compelling, is
practically difficult.
But if you can avoid use of directory listing, and outputs, the idea
works great.
David A. Lee
dlee@calldei.com
http://www.calldei.com
http://www.xmlsh.org
812-482-5224
Toman_Vojtech@emc.com wrote:
> To make things clear: this is not about Calabash, but about EMC's
> Calumet. The thing is that Calumet resolves relative source URIs
> against the base URI of the pipeline while the pipeline itself is
> resolved against cwd (or a custom base URI provided through Calumet API).
>
> Suppose cwd is /home/foo. Then, with the default configuration, the
> following code:
>
> String path = "some/path/to/pipeline.xproc";
> Source src = new Source(path);
> Pipeline pipe = engine.newPipeline(src);
>
> will attempt to load the pipeline from
> /home/foo/some/path/to/pipeline.xproc.
>
> However, the URIs of input docuemnts are resolved against the base URI
> of the pipeline. So if you do:
>
> PipelineInput input = new PipelineInput();
> input.addInput("source", new Source(path));
>
> with the intention of passing the pipeline itself as its input, the
> source will be expected to be in
> /home/foo/some/path/to/some/path/to/pipeline.xproc. I agree this may
> be confusing because you are expecting the source URI to be resolved
> against cwd, similar to the pipeline itself.
>
> --
>
> On the other hand, if your pipeline is at
> http://foo/pipelines/pipeline.xpl and you pass "../data/doc.xml" as
> the source URI, the engine will automatically load it from
> http://foo/data/doc.xml
>
> I am still trying to understand what should be the preferred behavior.
> I can see value in both...
>
> Regards,
> Vojtech
>
>
> ------------------------------------------------------------------------
> *From:* David A. Lee [mailto:dlee@calldei.com]
> *Sent:* Thursday, July 23, 2009 3:05 PM
> *To:* Florent Georges
> *Cc:* Toman, Vojtech; xproc-dev@w3.org
> *Subject:* Re: Calabash: Java API
>
> I think its me thats confused.
>
> Your right I was referring to the test driver, but itself it calls
> into the xproc core so its fundamentally the same issue.
> (but I was talking about calabash source, not sure which codebase
> your referring to).
>
> Looking at your example I only see the difference being :
>
>
> String path = "some/path/to/pipeline.xproc";
> input.addInput("source", new Source(path));
>
> vs
>
> input.addInput("source", new Source("pipeline.xproc"));
>
>
> The later works but not the former ?
> where is "pipeline.xproc" located?
>
>
> David A. Lee
> dlee@calldei.com
> http://www.calldei.com
> http://www.xmlsh.org
> 812-482-5224
>
>
>
> Florent Georges wrote:
>> 2009/7/23 David A. Lee wrote:
>>
>> Hi David,
>>
>>
>>> [...]
>>>
>>
>>
>>> Then inside that test is a reference to "testpipe.xml" (the
>>> xproc source).
>>>
>>
>>
>>> [...]
>>>
>>
>>
>>> Different threads in xmlsh have their own "current directory"
>>> but java doesnt support per-thread pwd's, so if calabash had
>>> resolved all relative URI's to the process-global PWD it would
>>> break given any relative paths.
>>>
>>
>>
>>> So I think this is the correct way to go both from an XML
>>> perspective and from a Java perspective.
>>>
>>
>> Well, in your example with the test suite, I think this is a
>> feature *of the test suite format* itself: how should embedded
>> URIs be resolved.
>>
>> About the PWD, my point is not about using the PWD, whatever is
>> is defined to be, but instead to use the same resolving mechanism
>> for different Source objects using a system ID, independently of
>> what they are use for (as pipeline document source or input
>> document source.)
>>
>> To take a concrete example, the following tries to apply an
>> XProc document to itself, but won't work:
>>
>> String path = "some/path/to/pipeline.xproc";
>> Source src = new Source(path);
>> Pipeline pipe = engine.newPipeline(src);
>> PipelineInput input = new PipelineInput();
>> input.addInput("source", new Source(path));
>>
>> Something like "some/path/to/some/path/to/pipeline.xproc cannot
>> be found" will be the error message. But the following will
>> succeed (a little bit surprisingly IMHO):
>>
>> Source src = new Source("some/path/to/pipeline.xproc");
>> Pipeline pipe = engine.newPipeline(src);
>> PipelineInput input = new PipelineInput();
>> input.addInput("source", new Source("pipeline.xproc"));
>>
>> But maybe I missed your point?
>>
>> Regards,
>>
>>
>
Received on Thursday, 23 July 2009 13:31:42 UTC