random comments on 2nd LC of WebArch

A few  points I noted while skimming through 
http://www.w3.org/TR/2004/WD-webarch-20040816/

I hope I'll be able to make a more thorough review, possibly through the
QA WG.

Editorial
- section 4.5.3 and 4.6 refers to [RDF10] which itself resolves to an
outdated version of the RDF Recommendation; it should probably link to
http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/ instead
(found through the TR ref checker [1] )
- it would be nice to add a class="glossary" to the <dl> of the glossary
section (see my previous comment on this [2])
- "A textual data format is one in which the data is specified as a
sequence of characters" ; I suggest mentioning somewhere something about
the encoding (ie, a big5-encoded text for a us-ascii processor may well
be considered as binary). e.g. "a textual data format in one in which
the data is specified in a defined encoding as a sequence of
characters".

- in 4.1 "thirty-two bit little-endian two's-complement and sixty-four
bit IEEE double-precision floating-point"; any reason not to use numbers
instead of "thirty-two", "two" and "sixty-four"? That impacts
readability.

- using <code> around non-English prose would make better usage of HTML
semantics (e.g. a:element & co in 4.2.2)

- in 4.2.2, "A format specification SHOULD include information about
change policies for XML namespaces." is XML-format specific, which
suggests that the subject of the good practice "format specification"
should be qualified in consequence

- regarding 4.2.4 "composition of data formats", "These relationships
can be mixed and nested arbitrarily" depends on the composition
mechanism defined in the data format; I don't think this apply to any
data format - I don't have an example handy, but I'm fairly sure there
are some types of XML you couldn't embed in a binary format for example.

- 4.5.7 has "These Internet media types create two problems" ; I think
"these media types" is too generic, since only the "text/*" are
concerned by the issued mentioned below that.

- since the document acknowledges itself that it will have other
editions (or are they versions?), it may benefit from using a numbered
shortname (ie webarch10 instead of webarch), and follows pubrules with
regard to forward linking to newer versions

Resources/Representations
- section 3.1 has 
"The term Information Resource refers to resources that convey
information. Any resource that has a representation is an information
resource"
 This makes several assumptions that it would be nice to explicit and
explain:
 * a resource having a representation implies that it conveys
information
 * is the set of Information Resources exactly the set of resources that
have a representation? of does it strictly include it?
 * the wording "a resource conveys" seems slippery;
 * since Resources can be anything, I assume they can be Representation
of resources, and thus representation of themselves; I have the feeling
this may lead to paradoxes but haven't fully investigated it; maybe
Resources and Representations should be in a different domain of
discourse?
 * if a resource R identified by the URI http://example.org/foo has 2
representations in conneg, GETtable at http://example.org/foo.xml and
http://example.org/foo.html, is there any relationship between
http://example.org/foo, http://example.org/foo.html and
http://example.org/foo.xml? if so, which? 

- in 3.3.1, "One cannot carry out an HTTP POST operation using a URI
that identifies a secondary resource." this seems very HTTP-specific;
any chance this refers to something broader? Otherwise, I suggest it
should belong to the HTTP spec, not to WebArch.

- in 3.3.2, "HTTP is an example of a protocol that enables
representation providers to use content negotiation."; are there any
other protocol with an associated URI scheme that allows such a thing?
If so, I suggest to add it as an example.

Data formats
- in 4.2.3 "Experience suggests that the long term benefits of
extensibility generally outweigh the costs" is probably too positive
without consideration for a trade-off; while I think this will be one of
the topics on which the QA WG will comment, I suggest that some
qualification along "benefits of a well-defined extensibility
mechanism..." instead

- in 4.2.4, "Each application must define how namespaces interact and
what effect the namespace of an element has on the element's ancestors";
is this application-dependent, or language-dependent? I believe the
latter, at least in most cases

Also, maybe having a good practice associated to this section would be
of interest; although the TAG has still open issues on the topic, I
think a well-crafted Good practice for XML languages is achievable.

Dom

1.
http://www.w3.org/2000/06/webdata/xslt?xslfile=http%3A%2F%2Fwww.w3.org%2F2004%2F07%2Freferences-checker&xmlfile=http%3A%2F%2Fcgi.w3.org%2Fcgi-bin%2Ftidy-if%3FdocAddr%3Dhttp%3A%2F%2Fwww.w3.org%2FTR%2F2004%2FWD-webarch-20040816%2F&
2.
http://lists.w3.org/Archives/Public/public-webarch-comments/2004JulSep/0007..html
-- 
Dominique Hazaël-Massieux - http://www.w3.org/People/Dom/
W3C/ERCIM
mailto:dom@w3.org