W3C home > Mailing lists > Public > www-archive@w3.org > June 2003

Re: Arch Doc: 23 June 2003 Editor's Draft [review thru 2.5.2]

From: Dan Connolly <connolly@w3.org>
Date: 24 Jun 2003 17:06:18 -0500
To: "Ian B. Jacobs" <ij@w3.org>
Cc: www-archive@w3.org, Tim Bray <tbray@textuality.com>, Stuart Williams <skw@hplb.hpl.hp.com>
Message-Id: <1056492377.8713.1020.camel@dirk.dm93.org>

On Mon, 2003-06-23 at 13:52, Ian B. Jacobs wrote:
> Comments welcome,
>  - Ian
> [1] http://www.w3.org/2001/tag/2003/webarch-20030623

No showstoppers so far, but my eyes are tired
after reading thru 2.5.2. I hope to finish
reading tomorrow.

Short version of comments...

1. Intro: I like the way the scenario weaves with the intro,
and the way terms are emphasized as they're introduced.
(not surprising, since I asked for these changes.)
I'd still like to see a figure of the "simple travel scenario".

2. Identification and Resources. one important issue
(change equivalence to coreference) but otherwise quite good,
thru 2.1.

2.2 is pretty good, but I still think the principle
about new URI schemes needs better justification.

2.3 is good, though the DDDS bit needs some work.

2.4 could use some polish.

2.5.1. Retrieving a Representation: OK, save some editorial suggestions

2.5.2. Safe Interaction: defn safe interaction too constrained?

comments as I read...

-- 1. Intro

"Agents (such as browsers and multimedia players) represent, describe,
and communicate resource state with a non-exclusive set of data formats,
used separately or in combination (e.g., XHTML,"

hmm... browsers represent resource state? Usually servers do, I think.
client agents interpret. Or something. hm...

"The representation might have consisted of XHTML with embedded weather
maps in SVG, for example."

It's your/our scenario; you/we can be concrete.
s/might have consisted/consists/
Likewise, s/most likely used/used/

"Throughout this document, we elaborate on this travel scenario to
introduce and illustrate architectural principles."

Overly meta for my tastes. suggest: move near "...balance the value of
brevity..." under 1.1. About this Document or strike.

--- 1.1.2. Scope
s/The authors/We/.

-- 2.1. Comparing Identifiers

I wonder if the 1st para shortens
the argument about global identifiers too much. I guess others
will have to say; the argument is too familiar to me.

I'm still not comfortable with the phrase "URI equivalence";
it suggests that it's a property of the URIs themselves.
But's more a property of how they're bound to resources.
Hmm... co-reference is a term I'm comfortable with for
this notion; is it widely understood?

google leads me to the sort of linguistic definition
I'd expect...

ah... it's also in the ordinary dictionary

Please do change "equivalence" to "coreference".

in 2.2 "Furthermore, the URI scheme specification suggests how an agent
can dereference the URI."

s/suggests/specifies/. You say "can" rather than "must" so
this doesn't rule out other ways of derferencing the URI.

"The Internet Assigned Numbers Authority (IANA) registry [IANASchemes]
maintains the mapping between URI scheme names and their

the registry *is* the mapping. IANA maintains it. So either

	IANA maintains a registry[IANASchemes] of mappings...


	The IANA registry[IANASchemes] is the mapping...

I still find the justification for
to be insufficient. But I don't have anything to suggest.
The weather: bit helps some, I suppose.

--- in 2.3:

strike "(in practice at least)". Where they don't depend
on DNS, they depend on IP address allocation, which is still
a centralized hierarchy. You could change it to "depend on DNS
and IANA infrastructure" perhaps.

Hmm... is DDDS really about a central registry for URNs?
   o  "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform
      Resource Identifiers (URI) Resolution Application" (RFC 3404) [3].
      This Application uses the DDDS to resolve any URI to a set of
      endpoints or 'resolvers' that can give additional information
      about the URI independent of its particular URI scheme.
 -- http://www.ietf.org/rfc/rfc3401.txt

Strike the DDDS bit or perhaps move to 2.8. Future Directions for Identifiers.

I'd like for 2.4. Fragment Identifiers to start by elaborating
the travel scenario-- oh; it's in there, just not at the beginning
of the section. Hmm... 1st para requires the reader to keep a lo
of stuff in their head. Better to start concrete and go abstract
here too, I expect.

"The fragment's format and resolution is therefore dependent on the
media type [RFC2046] of a retrieved representation, even though such
a retrieval is only performed if the URI is dereferenced."

Hmm... awkward at best. needs a forward pointer to the concept
of 'resolution' at least.

The paragraph contrasting XHTML and RDF seems to lack a conclusion.
And "In [RDF10], fragments refer to the subject of RDF description."
isn't grammatical and I'm not sure what it's saying. Hmm...

"only URIs without fragment identifiers work with intermediaries"

Oddly phrased; other URIs still work as designed with intermediaries;
the intermediaries just have no effect on them.

I think the case in 2.4.1. Fragment identifiers and content negotiation
is overstated. Just because mime types X and Y don't have exactly
the same fragment mechanism doesn't mean that there are *no*
#frags that work across them.

-- in 2.5. Dereferencing a URI

I could live without the "During URI resolution..." paragraph.
What does it add?

--- in 2.5.1

"The representations communicate the meaning of the resource."

hm... I mostly like that, but I think it's expressions
(i.e. URIs, documents, ...) that have meanings, not things
(i.e. not resources).

I think "... meaning of the URI" is better.

"As an example of dereferencing a URI to retrieve a representation"

we introduce the term "Resource retrieval" just a page or
so above; why not use it?

  "As an example of resource retrieval, ..."

hmm... not sure I like that either. But if we're not going
to use the term, there's no reason to import it, is there?

"suppose that http://weather.example.com/oaxaca is used
within an a element of an SVG document."

Don't change the example as we go; only elaborate it.
We found http://weather.example.com/oaxaca in a magazine,
not in an SVG document. Use another URI.

'may visit these resources."'

hmm... should 'visit' be a term in this web arch doc? maybe not...

In the list of specs, it would be nice to show the actual
links between the specs. i.e. go from the URI spec thru
the IANA scheme registry to the HTTP RFC. Say which section
of the SVG spec imports XLink.

"For example, do not assume that a URI that ends with the
string ".html" refers to a resource that has an HTML representation."


  For example, do not assume that all representations
  of http://example.com/page.html are HTML. The HTTP
  protocol does not constrain the media type based on the
  path; the server is free to return a PNG image

-- 2.5.2. Safe Interaction

"a safe interaction is one that does not cause a change to the state
of a resource"

I think that might be overly constraining. Some page counters
do in fact change state on GET. The point is that the client
user didn't ask for the change and isn't accountable for it.
We might do better to stick with a tautology:

  a safe interaction is one where the client does not commit
  to anything beyond the interaction and is not responsible
  for any consequences other than the interaction itself;
  for example a read-only query or lookup.

The "By following this link" scenario would be more clear
with a concrete URI or two:

  ... to publish a page http://example.com/oxaca/aboutNewsLetter
  that states "... terms and conditions..." with a
  link to http://example.com/oxaca/newsLetter because
  search services may link directly to
  http://example.com/oxaca/newsLetter and readers that follow
  such links may not have seen, let alone agreed to,
  the terms and conditions.

Suggest putting the "For more information..." bit in
in <em> or a box or something. It doesn't flow.

Dan Connolly, W3C http://www.w3.org/People/Connolly/
Received on Tuesday, 24 June 2003 18:05:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:32:08 UTC