Re: Review of June 23 webarch draft

On Wed, 2003-06-25 at 19:54, Tim Bray wrote:
> I think the issues below can all be classed as editorial, so I guess I'm 
>   OK with publishing even if these are not resolved:
> Status of: The para beginning "The primary changess in this draft are.." 
> should probably go since it describes inter-editor's-draft changes, and 
> will not be accurate for people who (presumably) haven't seen this since 
> the last TR draft.

Whoops. Missed that one in 26 June draft.

> Whole doc: will the "Editor's note:" thingies in pink be removed pre-pub?


> Seciton 1.1.1 has the wrong title

Merged 1.1.1 and 1.1.2 do moot.

> 2. Identification.  Recommend losing the second sentence of 1st para, 
> beginning "The Web relies", it's a little fluffy and I don't think 
> really adds much.

Replaced with some other text that was further done under
URI comparisons.

> 2. 2nd para: lose "geometrically"; I'm not sure whether we really mean 
> geometrically or exponentially or whatever, just say grows "as a 
> function of".

Changed to "grows exponentially as a function of". I think if the 
assumption is that the growth is linear, that's not interesting.

> 2. last para, phrase "have arisen naturally" is not quite what you mean, 
> how about "were not predicted."


> 2.2 2nd para 1st sentece is awkward, how about "Each URI scheme has a 
> specification which..."

I've made a slightly different change to talk first about scheme name,
then the spec that corresponds to it.

> 2nd para again, I think instead of "suggests" you mean "may specify"


> 2.2, in the middle somewhere, "since a huge range of deployed software" 
> should maybe be a "since a huge amount of deployed software", it's 
> really the amount as much as the range that incurs the cost.


> 2.3 I'm generally uncomfortable with this whole section because, as a 
> programmer, I can't figure out what this thing is trying to tell me to 
> do or not do, and if a seciton in here has no consequences on the 
> actions of programmers it should come out.  Also I don't remember any 
> discussion on which this is based. But for the moment I can live with 
> leaving it in.

Left in.

> 2.4 1st para, need a comma after "secondary resource", I mis-parsed the 
> sentence the first time I read it.


> 2.4 1st para last sentence, sentence is misleading, the meaning of the 
> secondary resource is determined by the media-type, the specifications 
> governing the representation format, by a bunch of things.  Also what 
> are the consequences of this on the actions of programmers?  Please just 
> lose this sentence.


> 2.4 3rd para.  I *hate* this sentence and I can't understand it.  The 
> statement of fact in the second sentence is important and useful and 
> this splodge of words just gets in the way.  I still think you're trying 
> somehow to justify the "therefore" in the second sentence, it would be 
> infinitely better to just *amputate* the "therefore".

I cleaned up a little. Some of this comes from RFC2396bis, I would note.

> 2.4 "fragments refer to the subject of RDF description" grammar problem, 
> either you mean rdf:description, or plural descriptions or something.

Grammar fixed (I think).

> 2.4 oaxaca#t34, don't like the example, I can't imagine seeing that, how 
> asbout oaxaca#pop to look up the probability of precipitation or 
> oaxaca#tomorrow to look up tomorrow's weather or something.

Changed to #tom.

> 2.6 bullet point "inconsistent use of an XML namespace URI", I have *no* 
> idea what you're talking about, either explain what you mean or 
> (preferably) remove.


I added that after some comments you made at a teleconf. I must
not have captured it!

> 3.2 title is awkward, how bout "Characteristics of formats and their 
> specifications"


> 3.2 bullet point "If you use Qualified Names" is grammatically 
> inconsistent with the rest of the bullet points which all begin the same 
> way.


> 3.2.1 The second and third <dt>'s (Author Needs/User Needs) have not 
> been subject to any TAG discussion (or did I miss it?) and read like 
> motherhood-and-apple-pie stuff.  If I'm right and htey haven't been 
> discussed I strongly request losing them.  I'm also queasy about 
> "Information Hiding", I think it belongs somewhere else in the spec, but 
> given that it does belong in the spec I'm OK with leavving it here for 
> the moment.

I added the second and third <dt>'s since I felt that your first <dt>
(for programmers) was one-sided. I realize that you tend to focus on
programmers, which may be why other considerations were not part of
your draft.

I'd just as soon lose all three of the first <dt>'s. For now I left
2 and 3 in.

> 3.2.4  1st sentence awkward, how bout "its ability to embed cross 
> references (hyperlinks)."


> 3.2.4 5th para, "some portion of its content".  You mean the 
> *representations's* content, not the resource's.


> 4.1 and 4.2.  I'd lose 'em.

> -- 
> Ian Jacobs (
> Tel:                     +1 718 260-9447

Received on Thursday, 26 June 2003 16:23:16 UTC