- From: Jacek Kopecky <jacek.kopecky@systinet.com>
- Date: Mon, 23 Feb 2004 16:12:49 +0100
- To: public-webarch-comments@w3.org
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 application/xhtml+xml 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 http://www.w3.org/TR/xmlschema-1/#Instance_Document_Constructions) 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.5.1. 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 confusion. 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 application/xml. 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 element/attribute? 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 conclusion. Jacek Kopecky Systinet Corporation http://www.systinet.com/
Received on Monday, 23 February 2004 10:13:19 UTC