Comments on June 27th 2003 Web Arch WD

Ian,

Below are the remaining comments on the June 27th draft that I said send
seperately yesterday. I've seperated them into Technical, Editorial and
Typos (in that order) and each follows through in document order.

There are quiet a few that I've labelled Technical... some may be editorial
on with further explaination.

Regards

Stuart
--


Technical
----------

--

Section 2:

"All important resources SHOULD be identified by a URI."

Is this saying that they should be identifiable by URI. Taking the car/brand
example from the discussion with Roy. One could argue that the car/brand is
(indirectly) identifiable by the use of a URI (as Roy showed in the
interpretation of a 'sentence' - a usage of a URI in some context). However,
in the example no URI was actually assigned to the brand or model of car.
The URI was assigned to a web-page.

So... are we saying that every important resource should be assigned a URI
(conceptually being labelled with at least one  - and implicitly that all
labels are different so that a given label is affixed to at most one
resource). Or are we saying that "All important resource should be
identifiable - through some referencing function - by URI." 

I think that this is an identity/identification distinction.

I also think it relates to the questions that Pat Hayes is asking us [a].
[a]  http://lists.w3.org/Archives/Public/www-tag/2003Jul/0129.html

--

2.2 URI Scheme:

Re thee list of URI scheme names... the relevant RFCs all speak of the
schemes URI's being used to 'designate' particular sorts of resource.

Seems that we have a number of words used in various works that feel like
synonymous but probably have subtle differences in nuance.: "designate",
"identify", "denote".

Do URI identify, denote, and/or designate?

--

2.2 URI Scheme:

"We note in passing that even more expensive than... is introducing a new
identification mechansim for the Web."

Hmmm.... don't know whether to suggest removing this (because of the "In
passing..." prefix), or seek an example... and as I sit to think about it,
IRI's as a new identification system for the Web come to mind - and it may
indeed prove to be a very expensive thing to introduce.

--

2.4. Fragment Identifiers

"Although the generic URI syntax allows any URI to end with a fragment
identifier, some URI schemes do not specify the use of fragment identifiers.
For instance, fragment identifier semantics are not specified for MAILTO
URIs."

Tricky... but aren't the 'semantics' of fragment identifiers bound to
media-types rather than URI schemes. Are there any URI schemes give an
account of fragment identifier 'semantics'. I wouldn't expect to find any.

Equally, I'm not aware of any URI schemes that prohibit the use of frag ids
in references made using that scheme.

--

2.4.1. Fragment identifiers and content negotiation

"This URI makes sense for the SVG representation, since SVG defines fragment
identifier semantics. However, the URI does not make sense for the PNG and
JPEG/JFIF representations; those specifications do not define fragment
identifier semantics."

Would like tighter language that 'makes sense' and 'does not make sense'. No
suggestions... sorry.

--

2.5. Dereferencing a URI

"Such operations are defined by the formats and protocols that make use of
URIs."

It's not at all clear to me how formats contribute to the *definition* of
'such operations'.

--

2.5.1 Retrieving a Representation

"As stated above, the authority responsible for a URI determines what the
URI identifies and which representations are used for interaction with the
resource."

I think this should be "...which representation media-types are used...."

--

2.6 URI Persistence

"Similarly, one should not use the same URI to refer to a person and to that
person's mailbox."

This impinges on the discussion in the metadataInURI threads re Mark Baker
using "mailto:distobj@acm.org" to identify himself in person. Roy spoke of
"referring functions" and context in [b] (and thread). 

[b] http://lists.w3.org/Archives/Public/www-tag/2003Jul/0102.html

--

2.8.3. Consistency of fragment identifier semantics among different media
types

"There has been some discussion but no agreement that new access protocols
should provide a means to convert fragment identifiers according to media
type."

I am not aware of any such dicussion inside or outside the TAG, can you
provide a reference. Secondly, I have no idea what it means to "convert
fragment identifiers according to media type."

--

3 Representations

"A representation is data that represents or describes the state of a
resource."

Are 'represents' and 'describes' being used as synonyms? If so... pick one.
If not, are they covering some uncertainty or confusion about what it is
that a representation represents? Again I think this intersects with Pat
Hayes questions [a].
[a]  http://lists.w3.org/Archives/Public/www-tag/2003Jul/0129.html

--

3.2.1. Desirable Characteristics of Format Specifications

"Attention to Programmer Needs 
... In particular, the specification SHOULD be in part formal and
mathematical, rather than relying exclusively on narrative."

Advice I think we should take to heart ourselves...

--

3.2.2.2. Final-form v. Reusable

"In general XML-based data formats are more re-usable and repurposable than
the alternatives, although the example of XSL-FO shows that this is not an
absolute."

This feels like a gratuitous side swipe at XSL-FO. Needs to either be
explicit about the 'complaint' or struck from the document.

--

3.2.4. Embedding Hyperlinks in Representations

"Representation formats based on XML SHOULD use at least the XPointer
Framework and XPointer element() Schemes for their fragment identifier
syntax."

Roy has expressed some reservations about Xpointer based fragment identifier
syntax. I don't think that the TAG has really discussed it or formed an
opinion. But there is at least one voice on the TAG that object to this
statement - this is relevant to abstractComponentRefs-37.

[c] http://lists.w3.org/Archives/Public/www-tag/2003Jul/0013.html
[d]
http://lists.w3.org/Archives/Public/www-xml-linking-comments/2002OctDec/0039
.html


--

Editorial:
----------
Section 2: Identification and Resources.

"Web Architecture start with Uniform Resource Identifiers (URI) defined
by..."

I would prefer: "Uuniveral Resource Identifier (URI) defined by... are
central to Web Architetcture."

--

Section 2: Identification and Resources.

"When a representation of one resource refers to another resource with a
URI, a link is formed between the two resources."

This suggests that a respresentation (of the first resource) is necessary in
order for a link to be formed. Suggest:
"When one resource refers to another resource with a URI, a link is formed
between the two resources."

Even that seems overly constraining on how links are formed. Also, give the
discussion with Roy there is some question over quite what the link is
between... a link/reference to a brand of car or to a web-page (or both, one
indirectly via the other).

--

Section 2:

"The value of the Web grow exponentially as a function of the number of
linked resources (the "network effect")."

I can take or leave this... feels like a bit of marketing polemic. 

--

2.4.1. Fragment identifiers and content negotiation

"This URI makes sense for the SVG representation, since SVG defines fragment
identifier semantics. However, the URI does not make sense for the PNG and
JPEG/JFIF representations; those specifications do not define fragment
identifier semantics."

Would like tighter language that 'makes sense' and 'does not make sense'. No
suggestions... sorry.

--

Section 2.6 URI Persistence

"...or the work itself in an abstract sense (for example, using RDF),..."

Don't understand the need of the parenthesised aside. Suggested it be
deleted.

--

3. Representations

" 1. Electronic data expressed in one or more formats (e.g., XHTML, CSS,
PNG, XLink, RDF/XML, and SMIL animation) used separately or in combination. 

  2.Metadata about the representation, such as the Internet Media Type
(defined in RFC 2046 [RFC2046]). The Internet Media Type is the key to the
correct interpretation of a resource representation, and governs the
handling of fragment identifiers. When transferred by a Web protocol, a
representation often includes metadata about both the representation and the
message bearing the representation (for example, some HTTP headers).

Web agents use representations to modify as well as read resource state."

Seems to be struggling for a term for the non-metadata part of a
representation. "Content" and "Content Metadata" come to mind, but they are
not ideal.

Also, the last bit is wrong wrt to our discussion at our Feb F2F... a
representation does NOT contain message metadata. I think Roy has made this
point already.

Finally suggest s/read/retrieve/ in the final sentence quoted above.

--

3.2.3. Presentation, Content, and Interaction

I was unable to make sense of this section as is. However more, possible a
replacement, is expected.


--
Typos
-----

2.5.1 Retrieving a Representation: List item 6
s/but/by/

3 Representations: list item 5
s/result/resulting/

3.2.2.1. Binary v. Textual: 2nd paragraph
s/so represented are include/so represented include/

Received on Wednesday, 16 July 2003 11:10:31 UTC