- From: Tim Bray <tbray@textuality.com>
- Date: Sun, 10 Aug 2003 13:47:28 -0700
- To: WWW-Tag <www-tag@w3.org>
Coming to you from a farm in Southeastern Saskatchewan. ** Abstract 1. The statement that the web necessarily relates "Information sources and services" strikes me as unnecessarily limiting and in fact wrong, particularly in view of the goals of the Semantic Web. 2. The assertion that the web of information spans the Internet is unduly limiting, the archtecture of the web would stretch fairly easily to further different kinds of networks that are entirely unrelated to the Internet. To be pedantic, Web technology works just fine on many highly-secure intranets that are disjoint from the Internet. And if the assumption is that the use of the IP protocol family is necessary to the Web, that is also wrong. 3. The phrase "human component" is vile, let us refer to people as people. Furthermore, the distinction between "software" and "machine" components has become so fuzzy as to lose usefulness. 4. When we say "Architecture defines" I think we mean "Web Architecture defines" 5. "grow indefinitely across ... mediums." "Media" please. 6. I am generally uncomfortable with the use of Roy's new text (which has good stuff in it) by wholesale replacement of what was there before. ** Status of 7. "The latest status..." needs a link. ** 1. Introduction 8. To a large extent, this echoes the language of the Abstract, and many of my comments 1-7 apply again. 9. Disagree that this is the Web's "primary goal". 10. s/will continue to grow/grows/ 11. 2nd para, s/simple/vacation/ 12. General comment, if you distinguis URIs by <code>, you probably don't need the quotation marks and parentheses and so on that have been scattered in the doc to date. 13. We may be a bunch of middle-aged white guys, but could our scenario perhaps use a slightly less vanilla name, how about "Nadia" or "Michiko" or some such. 14. General comment, we say sometimes "software", sometimes "agent", and sometimes "component", let's establish a house style and stick to it. 15. <ol> item 2: s/In the/In this/ 16. <ol> item 3: s/information/state/, and lose the whole rambling phrase beginning "... corresponding to" 17. same item, s/e.g./including/ 18. same item, s/etc./and so on/. **** 1.1 About 19. s/Architecture/Web Architecture/ **** 1.1.1 Audience 20. Lose last para "We assume..." it adds nothing. **** 1.1.2 Scope 21. on the architecture of the Web as a whole. s/principles related to//. 22. 2nd para s/is designed/attempts/ **** 2. Iddentification 23. "..will agree upon a shared set of identifiers and on their meanings." 24. For the last time, saying the "the value grows exponentially" is just bullshit, because the value is not susceptible to direct measurement. The traffic, or volume, or link count, or whatever may grow thus, but this statement as it is now constitues arm-waving. My excellence as a person grows exponentially as a function of my Buddha-nature, so there. *** 2.1 Comparing Identifiers 25. "Please refer to section 6.3 of [URI]..." - I'm pretty sure it says almost nothing in there about reducing the risk of false *positives*. 26. The use of "components" as opposed to agents or software or whatever really stands out in this section. ***** 2.2 URI Opacity 27. The paragraph beginning "The more resource metadata is included..." really needs an example or something, it doesn't stand alone successfully. **** 2.3 URI Schemes 28. Sentence beginning "The name refers..." suggest: "Each URI scheme has a normative specification..." 29. 1st para, last setence: s/specifies/may specify/, URNs for example don't. 30. last <ul><li> s/general purpose/general-purpose/ *** 2.4.1 Secondary resources... 31. Consistency in capitalization please in the title 32. Sentence "The URI that identifies the secondary..." haven't we already said this? Feels redundant. 33. "The syntax and semantics of those identifiers are defined by the set of representations..." Huh? WRong. The syntax and semantics are defined by the normative scheme specifification, which *may* call for interpretation relative to the contents of a representation. 34. Last para: here is "user agent", no caps, once again we need to get the agent/component/software house in order **** 2.4.2 Fragment identifiers and 35. s/provide/provides/ 36. Busted " after zicatela, see comment above about not needing them around URIs. ***** 2.5.1 Restriebing 37. Title of Good Practice: s/Resource descriptions/Available representations/ 38. General problem in this section, you could read it as saying that the software fetches normative specs at runtime, in fact what happens is that there is a succession of dispatches to software modules which implement the respective specifications. Slight rewrite could make this clear. *** 2.5.2 Safe 39. s/subscription/subscribing/ for consistency *** 2.6 URI Persistence 40. phrase "rather than a constraint imposed". What we're really saying is that using a particular URI scheme is no guarantee that URIs are persistent, nor that they are not persistent. Thus the notion that URNs are necessarily persistent, and HTTP URLs aren't, is wrong. So why don't we just say that? In particular we're talking about URI schemes, not "technology" in general. 41. s/Large Company, Inc./Example, Inc./ these rules apply to small organizations as well. 42. s/as though it was the URI of the organization itself/to identify the organization itself/ 43. Paragraph about "indirect identification", I'm not sure it's helpful. If others are fine with it I am too. 44. "As another example of URI ambiguity, saying..." is grammatically strained. "Saying that the URI http:.. identifies "Moby Dick" is another example of ambiguity, because this might be interpreted..." *** 3. Interaction 45. Please typographically distinguish our stories. There is no reason why the lead-off story has <ul><li> and this one doesn't. I'm not sure either is better, but we need consistency. **** 4.1 Authoritative 46. Do we really mean succesful communication *about* a piece of information or successful communication *using* a piece of information? I think the latter. 47. This section is awfully long. Does the section on inconsistencies deserve its own number/title? *** 4.2 Interoperability 48. s/can be very expensive/are very expensive/ **** 4.5 Binary and 49. s/linear// *** 4.9 Hyperlinks 50. "All of the current common linking mechanisms identify resources by URI reference." This sentence needs work. First, they really identify them by URI, although the embedded syntax might be a reference. Second, if this is *not* true they've nothing to do with the Web, this is not just a passing observation that we're making here. -- Cheers, Tim Bray (ongoing fragmented essay: http://www.tbray.org/ongoing/)
Received on Sunday, 10 August 2003 23:20:12 UTC