Re: Constant Inputs during Iteration

Alex, Milowski wrote:

 >> 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.
 >
 > You don't have the document that is in eXist.  You have to go
 > retrieve that document.

Of course. It is reasonable to expect that if you specify an HTTP URI
on an @href attribute, then that URI is going to be dereferenced and
that the stream of bytes received will be parsed into an XML
document. Now possible questions are:

o At what point during pipeline execution should an implementation
   dereference URIs, in particular HTTP URIs? Do we even specify that?

o Do we allow implementation to follow HTTP caching mechanisms when an
   HTTP scheme is provided? Do we even specify that?

 > If your pipeline implementation determine that there is a static
 > reference to a document and pre-fetches that or some other kind of
 > optimization, then it will have the wrong version of the document.

Yes. But note how a web browser performs such optimizations: it does
so based on HTTP caching mechanisms.

 > In this case, you're talking about a side-effect to a document that
 > you've caused.  I think we should have the model where you *need* to
 > retrieve that document again to see the side-effect.  I don't think
 > that means that the input that has previously be computed changes to
 > reflect that side-effect.

I think it is possible to go both ways. I clearly see an argument in
favor of handling the side effect (my eXist use case) based on common
HTTP semantics. I also don't think we should go as far as mandating
that implementations support HTTP caching as that would be an extra
burden on implementors. So in effect I am saying that this would be
implementation-dependent.

 >> I think that your suggestion to use such as step leads to a much
 >> "madness" as my own above ;-)
 >
 > Because you need to recognize you have a side-effect and handle that.
 >
 > The case the worries me is where you retrieve a resource via URI as
 > an input and it changes during execution but you don't want the
 > change.  You now have no control over that because the input has
 > been fetch automatically and you can't prevent that.

Well you do have a way to control that, as I said, by retrieving the
resource outside p:for-each. Our semantics then ensure that the
document remains constant for all iterations of the p:for-each.

The truth is that whichever way you go, you have a workaround. You say
mine is (or leads to) "madness", but again I don't see a qualitative
difference between that workaround and your "load step" workaround.

-Erik

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

Received on Wednesday, 4 October 2006 10:37:14 UTC