AWWW last call comments

Hello all, 

here are my comments on the Last Call working draft of the AWWW
document. The comments are divided into editorial and "probably more
substantial" below. Overall, I have to congratulate on the readability
of the document.

Every comment starts with the section number where it applies.

Editorial issues:

1 under first story in point 2, application/xml+xhtml should be

1.2, "principles apply *to* across all three bases" - drop the "to"

1.2.1 2nd para: "The fact, for example, that *the* an image..." - drop
the "the"

2.3.1 last sentence misses a 'when': "URI ambiguity arises *when* a URI
is used to identify two..."

3.6.1 should point to 4.5.4 as a good example

3.6.2 second bullet should probably provide a better example, mentioning
the intended semantics of the resource

4 second para - something missing where the X is in "Below we describe
some characteristics of a data format X make it easier to integrate into
the Web architecture."

4.3 remove the 'the': "Experience shows that *the* allowing authors to
separate content,..."

4.3 last sentence missing '-ity': "this follows from the principle of
orthogonal*ity* of specifications".

4.5.3 para below story: "(for example, suppose that the "p" element is
defined in two or more XML formats)" - I suggest that a more concrete
example be added, like mentioning two different meanings possible for
the element "p".

4.5.3 "The type attribute from W3C XML Schema..." should be
distinguished from the type attribute on element declarations; the
customary reference is xsi:type. The whole paragraph doesn't mention
"instance" and says incorrectly that the type attribute is defined the
W3C XML Schema namespace (there are multiple XML Schema namespaces, see
last para of

5 A Link does not need to be internal to a representation of any of the
two (or more) resources between which there is a relationship, the
definition might want to mention that.

5 Secondary resource definition doesn't parse, probably should drop the
second "that".

Issues that are probably more than editorial:

Some of the "stories" in the document seem pointless to me, I suggest
dropping or expanding them: expand story in 2.6; story in 3.6 is too
unlikely and extreme, might be dropped; expand story in 3.6.3; expand or
drop story in 4.5.3.

3.5: the story should give an example of a safe interaction; perhaps
with side effects like an access counter. Any change may affect story in

3.1: does a URI *reference* or identify a resource? Is there even a
difference? I'm unsure here, but the choice of words might cause

3.1: is modification of a resource by POST/PUT/DELETE also
"dereferencing"? I thought dereferencing meant GET.

3.2: "A representation is an octet sequence that consists logically of"
data and metadata. Is the metadata also a part of the octet sequence? I
thought the octet sequence was only the data, that the metadata was
associated to it. Same applies to definitions in section 5. I suggest
Representation to consist of data and metadata, Representation data
being an octet sequence expressing resource state. In other words, the
actual thing that is an octet sequence to my software is the data, not
the whole representation.

3.6: should the section be called "Resource management" as opposed to
"Representation management" ?

3.6.3 should better relate to legislation attempts on deep linking
(perhaps just mentioning them?)

4 first para says "before inventing a new data format, designers should
carefully consider re-using one that is already available" but the whole
doc doesn't seem to say why all XML formats shouldn't be

4.5.2 suggests using XPointer framework and XPointer element() Schemes,
I think the xpointer() scheme (in development in W3C) should also be
pointed to.

4.5.3 "Namespaces in XML provides a mechanism for establishing a
globally unique name that can be understood in any context." What does
it mean to understand a name? Should this say that the globally unique
name can unambiguously identify the intended meaning of the

4.5.5 below the Good Practice: QName Mapping - the section (or some
other) should probably say more on the interaction of QName Mapping,
fragment identifiers in XML (4.5.8) commonly used for this mapping and
namespace documents (4.5.4)

4.5.6 this section lacks a conclusion, any kind of statement on what
should/should not be used. Or words that at the moment there is no

                   Jacek Kopecky

                   Systinet Corporation

Received on Monday, 23 February 2004 10:13:19 UTC