Re: Constant Inputs during Iteration

/ Erik Bruchez <> 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,

Norman Walsh
XML Standards Architect
Sun Microsystems, Inc.

Received on Thursday, 12 October 2006 13:56:17 UTC