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

On Tue, 2003-06-24 at 18:06, Dan Connolly wrote:
> 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.

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

Added "servers", deleted "represent, describe"

> "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/

Done.

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

Done.

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

Done.

> -- 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...
> http://www.sil.org/linguistics/GlossaryOfLinguisticTerms/WhatIsCoreference.htm
> 
> ah... it's also in the ordinary dictionary
> http://dictionary.reference.com/search?q=coreference
> 
> Please do change "equivalence" to "coreference".

Not done. I expect we'll discuss this more.

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

Done.

> 
> "The Internet Assigned Numbers Authority (IANA) registry [IANASchemes]
> maintains the mapping between URI scheme names and their
> specifications."
> 
> the registry *is* the mapping. IANA maintains it. So either
> 
> 	IANA maintains a registry[IANASchemes] of mappings...
> 
> or
> 
> 	The IANA registry[IANASchemes] is the mapping...

Done.

> I still find the justification for
> http://www.w3.org/2001/tag/2003/webarch-20030623#pr-new-scheme-expensive
> to be insufficient. But I don't have anything to suggest.
> The weather: bit helps some, I suppose.

No change.

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

Changed to "depend on DNS and IANA"

> Hmm... is DDDS really about a central registry for URNs?
> no: 
>    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.

Moved to future directions and edited.

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

Done.

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

Cleaned up.

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

Deleted last 2 sentences, moved to future directions, added references
to TAG issues.

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

Fixed (I think).

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

Change notion of "same" to "compatible".

> -- in 2.5. Dereferencing a URI
> 
> I could live without the "During URI resolution..." paragraph.
> What does it add?

I added reference to draft get7 finding since one point to
emphasize is value of URI addressability and its relation to
metadata outside the URI (i.e., choice of access mechanisms).

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

No change to "meaning of the resource." I think we'll need to
discuss that. [Dan and I have discussed this somewhat already,
but the phrase "meaning of the resource" is frequently used
in the arch doc.]

> "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?

Done.

>   "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?

Fixed.

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

Fixed.

> 'may visit these resources."'
> 
> hmm... should 'visit' be a term in this web arch doc? maybe not...

Not added.

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

Yes, I elaborated with more specs.

> "For example, do not assume that a URI that ends with the
> string ".html" refers to a resource that has an HTML representation."
> 
> suggest:
> 
>   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
>   representation.

Done.

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

Done. Also improved dfn of unsafe.

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

Done.

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

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

Received on Thursday, 26 June 2003 16:17:25 UTC