Commentary on Aug 1st draft

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 &quot; 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