Re: Constant Inputs during Iteration

Alex,

 >> o Stores a document into eXist as a step of the iteration
 >>
 >> o Retrieves the updated version from eXist using the eXist REST API
 >>   during the next iteration, with an HTTP URI like:
 >>
 >>   http://example.org/exist/rest/db/latest.xml
 >
 > It isn't the URI label to document that remains constant.  It is the
 > input mapping that remains constant.

Sorry I can't make sense of this sentence.

 >> In this case, the document retrieved with that HTTP URI would need to
 >> be up to date during each iteration. In other words, while the URI is
 >> static, the document is not static, and I think it would be wrong in
 >> this use case to require that it be static. And if you want it to be
 >> constant for the iteration, you have a simple workaround: you can
 >> retrieve the resource outside p:for-each!
 >
 > I think that way "leads to madness".

My comment on this further below.

 >> Also, requiring all static URIs to be constant requires the
 >> implementation to use a sort of cache, even for "file:" URIs. I am not
 >> sure that this is necessary.
 >
 > The consequence of not having this is that during iteration the
 > results from two different applications of the subp-ipeline could
 > inexplicable be different unless you knew that "the world changed"
 > during execution.  Given that execution times will generally be
 > short, this is really going to confuse the user.

Debatable. With my eXist use case, the user has updated the HTTP
resource and can reasonably expect the update to be taken into
account. I would argue that making the document constant in this case
is confusing to the user.

 > If you want to "retrieve" a document during execution of a
 > sub-pipline as part of an iteration, you should use some kind of
 > "load" step to ensure that you have the most current version of the
 > resource.  That allows the intent of the author to be explicitly
 > encoded in the pipeline.

Debatable too. Why should I use a "load" step in this REST world
instead of using a regular HTTP URI that follows HTTP semantics
(including caching semantics!)?

I think that your suggestion to use such as step leads to a much
"madness" as my own above ;-)

-Erik

-- 
Orbeon - XForms Everywhere:
http://www.orbeon.com/blog/

Received on Monday, 2 October 2006 17:15:41 UTC