Re: Constant Inputs during Iteration

/ Erik Bruchez <ebruchez@orbeon.com> was heard to say:
| 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?

I don't think we have to say when, though I'd like to say that a URI,
once dereferenced, it won't change. This is the same restriction that
XSLT places on input document()s.

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

That's another layer in the protocol stack. I don't think we should
say anything about it. We certainly can't forbid the user from having
a caching proxy.

|> 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.

I don't think browser caching has anything to do with HTTP.

|> 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.

Implementation dependent means not interoperable.

If we say that a URI must be cached locally (this is independent of
protocol and any protocol-based caching; I may be confused about what
sort of caching you were describing above), then it doesn't matter when
a URI is retrieved.

If we don't say that it's cached, then I think we'll have to say that
it must not be cached. Having said that, in order to have any sort of
interoperability, I think we'll have to have a pretty detailed story
about execution order.

On balance, I'm strongly in favor of the former.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh
XML Standards Architect
Sun Microsystems, Inc.