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

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.


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.

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

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.

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

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

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 I stop here. It's getting rather long (and late)

Cheers
Olivier

Received on Monday, 29 September 2003 18:07:02 UTC