Re: Naming ports vs. naming documents

/ Alessandro Vernet <avernet@orbeon.com> was heard to say:
| On 5/2/06, Norman Walsh <Norman.Walsh@sun.com> wrote:
|> | It looks to me like we are getting closer to a consensus on the issue
|> | of how steps are connected. Is is fair to say that this group thinks
|> | that the primary way to connect the output A of a step with the input
|> | B of another step, is to assign a label to A and make a reference to
|> | that label in B?
|>
|> That's what I think, yes.
|
| Would it be reasonable to put this on our agenda for our next call to
| record consensus on this matter, if in fact there is a consensus?

This came up in the discussion of the "resource manager". That's where
we're going to start again tomorrow. If we don't reach consensus on
this point in the course of those discussions, I'll add an explicit
issue for it and make sure we discuss it asap.

|> I appreciate that this approach makes the connection more explicit,
|> but by making the URI/resource mapping explicit at the step-level, I
|> think it introduces the possibility of some strange behavior. What's
|> more, I don't believe that it aids implementation in any way.
|
| I am convinced that there are benefits to allowing URIs to be used in
| a step to read the output of another step. (In fact we allow this in
| XPL.) However, I can also see that there is a plenty of room for
| discussion on the topic:

I think it's essential that we support this sort of dependency. I
haven't heard any objection to the principle, but we have a few
different mechanisms for making the dependency explicit on the table.
(If anyone objects, now would be a good time to say so.)

| 1) It is easy to intercept URI resolutions in some environments (we do
| this every day in Java-land, and I imagine it is the same on .NET),
| but not easily feasible in others. Should we then make this an
| optional feature of the language, or have multiple levels of
| conformance? Are we comfortable with the implication this has on
| interoperability?

No multiple levels of conformance. No optional features. :-)

If the engine knows that component B relies on the output of A, it can
run A to completion before it begins B. If A attempts to produce
output at URIs where the engine can't serialize them, I think that'll
fall under the category of resource error.

| 2) I am not convinced that reusing schemes is a good idea.

I am certain that it is. As Jeni points out, WebArch discourages the
invention of new schemes.

| I don't
| feel comfortable with a step producing a document for
| http://www.google.com/xhtml and then having another step read that URI
| and get something different than the Google home page.

I'm entirely comfortable.

| There is an
| semantic attached to the http scheme, and an expectation of what XML
| document is returned when reading http://www.google.com/xhtml.

The expectation that a GET of that resource actually every contacts
the server at www.google.com is naive. It may be in your browsers
local cache, in your corporate proxy server, or in any number of proxy
servers world wide.

I don't mind if some implementations fall over because they can't
write to http://www.google.com/xhtml but for implementations that do
act as a resource manager, it can "just work".

The extent to which this is an interoperability issue is something we
can discuss.

| 3) Then there is the issue discussed here: what should be the scope of
| someURI? Should it be the step where it is defined (as I suggest) or
| larger (as I get from your proposal).
|
| It looks to me like we'll need a fair amount of discussion to get to a
| consensus regarding those issues. Discussion is good, but so is
| producing a candidate recommendation of the language out of the door
| in the time frame defined in our charter. With this in mind, I
| wouldn't feel terribly uncomfortable if we keep this feature in store
| for a "1.1 version" of the language.

Given that I think it's essential that we allow resource-dependencies
to be supported, I'm not sure we can push this off to 1.1. But I could
be wrong.

                                        Be seeing you,
                                          norm

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