Re: Arch Doc: 26 September 2003 Editor's Draft (review of some terms)

On Mon, 2003-09-29 at 17:02, Olivier Fehr wrote:
> Abstract
> <quote>
> ...of Web resources that are interconnected via URIs..
> </quote>
> ->probably better to say 'can be interconnected', as they may exist in
> the same information space without any relation to each other.


I propose to change "that are" to ", which are".

> 2.1 Comparing Identifiers
> <quote>
> ..,it is generally not possible to be sure that two URIs that are not
> equivalent identify different resources.
> </quote>
> This follows from 'Web architecture does not constrain resources...' in
> 2.

Does it? What if the Web architecture allowed us to use more than
one URI to identify a resource, but in all cases it was possible
to determine that from examining the URIs alone. I don't think
the part about "generally not possible to be sure" is necessarily
implied by the sentence you are referring to.

> <quote>
> Agents should not assume...
> /Oaxaca and
> /Oaxaca identify the same resource,...
> Thus, the parties responsible for weather.example.com should not use...
> </quote>
> I don't think the 'thus' is necessarily correct, as the responsible for
> weather.example.com can simple determine, i.e. stipulate that both
> reference the same, whereas a agent is not free to assume that
> equivalence lacking a clear statement of equivalence from the
> responsible authority.

I'm not sure I've understood your point, since you seem to
be agreeing with the point of the paragraph.

> 2.2 URI Opacity
> 'Good practice'
> Somehow confirms my believe above
> <quote>
> The example URI used in ... suggests...
> On the other hand, the "mailto"...
> </quote>
> As you say, the normative specification makes the difference. By
> assuming that a certain type of resource can be constructed by guessing
> the parts of an URI, an agent might well end up with something
> completely irrelevant to her/him/it.

I'm not sure if you are proposing a specific change here.

> <quote>
> Editor's note...metadataInURI-31...
> </quote> 
> For web services there is a WSD(L), for other content there is no such
> thing as a WCD (Web Content Description), so usually there is now way of
> knowing what is behind the starting URI, e.g. http://www.w3.org.

I think there is RDF work as well; see the sections on future
work for identifiers.

> 2.3. URI Schemes
> <quote>
> If the motivation behind registering a new scheme is to allow an agent
> to launch...such dispatching can be achieved by registering...
> </quote>
> While I agree, I would also add this might be an alternative if some
> patent holders have their way...



> <quote>
> The user of unregistered URI schemes is discouraged...
> </quote>
> Yes. After all an agent would have to support this scheme, thus making
> that approach unsuitable for broad Internet use. While I could do
> something like this internally, I would be building something
> proprietary which shouldn't be done except for very valid business
> reasons, but then I can register it...

Right.

> 2.5.2. Safe Interaction
> This seems to be a very limited definition of 'safe' from the agent's
> point of view. Seems more like a concept of liability or obligation...

I think that's how "safe" is being used in the relevant RFCs.

> I think I stop here. It's getting rather long (and late)

Thank you for your comments, Olivier.

 - Ian

-- 
Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
Tel:                     +1 718 260-9447