Re: Naming ports vs. naming documents

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?

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

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?

2) I am not convinced that reusing schemes is a good idea. 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. 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. This is
discussed with a suggested solution on
http://www.w3.org/Bugs/Public/show_bug.cgi?id=3113#c14

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.

Alex
--
Blog (XML, Web apps, Open Source):
http://www.orbeon.com/blog/

Received on Wednesday, 3 May 2006 00:27:23 UTC