- From: Ian B. Jacobs <ij@w3.org>
- Date: 26 Jun 2003 16:17:12 -0400
- To: Dan Connolly <connolly@w3.org>
- Cc: www-archive@w3.org, Tim Bray <tbray@textuality.com>, Stuart Williams <skw@hplb.hpl.hp.com>, ij@w3.org
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