W3C home > Mailing lists > Public > public-webarch-comments@w3.org > January 2004

Comments on 9 December 2003 draft

From: Tim Goodwin <tjg@star.le.ac.uk>
Date: 7 Jan 2004 16:57:33 -0000
Message-ID: <20040107165733.22606.qmail@mail.star.le.ac.uk>
To: public-webarch-comments@w3.org

I have read the 9 December 2003 draft of the "Architecture of the
World Wide Web" document, and have a number of suggested improvements.
They mainly fix simple typos, but I've also highlighted a couple of
places where I feel the language could be improved.

I have marked insertions like ^this^, deletions like -this-, and
replacements like /that/this/.

Hope this is useful.

Regards,

Tim.
-- 
Tim Goodwin
University of Leicester


1.1

    The addition ^of^ a conformance section is not likely to increase
    the utility of the document.

1.1.3

    Authors of protocol specifications in particular should invest
    time in understanding the REST model and consider the role to
    which ^each^ of its principles could guide their design:
    statelessness, clear assignment of roles to parties, uniform
    address space, and a limited, uniform set of verbs.

Even with the missing "each" replaced, the sentence doesn't make much
sense to me: roles don't guide.  Replace "role" with "degree"??

1.2 

    A number of general architecture principles apply to -across- all
    three bases of Web architecture.

Either "to" or "across" will do, but not both!  The former seems less
jargony to me.

    The fact, for example, that -the- an image can be identified using
    a URI without needing any information about the representation of
    that image allowed PNG and SVG to evolve independent^ly^ of the
    specifications that define image elements.

1.2.2

    Some examples...

I recommend using semicolons between each list item, and a full stop
(period) at the end of the last.

2.1

I initially found this whole section rather confusing.  Specifically,
the juxtaposition of these two sentences at the beginning of the
section makes little sense.

    Thus, URIs that are not identical (character for character) do not
    necessarily refer to different resources. The most straightforward
    way of establishing that two parties are referring to the same Web
    resource is to compare, as character strings, the URIs they are
    using.

(There's also a full stop missing at the end of the next sentence
after these.)

I would suggest moving "The most straightforward way..." to the very
beginning of the section, then starting the next sentence with
"However, ...", like this.

    The most straightforward way of establishing that two parties are
    referring to the same Web resource is to compare, as character
    strings, the URIs they are using.  However, web architecture
    allows resource owners to assign more than one URI to a resource.

To my mind, this makes the ideas presented in this section flow much
more smoothly.

2.3.1

    URI ambiguity arises ^when^ a URI is used to identify two
    different Web resources.

4.1

    Below we describe some characteristics of a data format ^which^
    make it easier to integrate into the Web architecture.  This
    document does not address generally beneficial characteristics of
    a specification such as readability, simplicity, attention to
    programmer goals, attention to user needs, accessibility,
    /and/nor/ internationalization.

    It is important to emphasize that intuition as to such matters as
    data size and processing speed /are/is/ not a reliable guide in
    data format design; quantitative studies are essential to a
    correct understanding of the trade-offs.

4.2

    For more information on -about- versioning strategies and agent
    behavior...

4.2.2

    The policy sets expectations that the Working Group responsible
    for the namespace may modify it in any way until a certain point
    in the process ("Candidate Recommendation") at which point W3C
    constrains the set ^of^ possible changes to the namespace in order
    to promote stable implementations.

4.2.4

    RDF allows well-defined mixing of vocabularies, and allows text
    and XML to be used as -a- data type values within a statement
    having clearly defined semantics.

4.3

    Experience shows that -the- allowing authors to separate content,
    presentation, and interaction concerns promotes reuse and
    device-independence (see [DIPRINCIPLES]); this follows from the
    principle of orthogonal -of- specifications.

This sentence reads rather awkwardly: it's hard to find the finite
verb.  Here is a possible rewording (which replaces the active with
the passive voice, generally considered a Bad Thing, but in this case
it pulls "reuse and device-independence" to the beginning, where they
belong).

    Experience shows that reuse and device-independence are promoted
    by allowing authors to separate the concerns of content,
    presentation, and interaction; this follows from the principle of
    orthogonal specifications.  See [DIPRINCIPLES].

4.5.4

    Nadia receives -a- representation data from "weather.example.com"
    in an unfamiliar data format.

END
Received on Wednesday, 7 January 2004 12:23:17 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 7 January 2004 12:23:18 EST