Re: Comments on June 27th 2003 Web Arch WD

On Wed, 2003-07-16 at 08:09, Williams, Stuart wrote:
> --

Thank you Stuart. I will incorporate some changes into the next Editor's
draft. My comments below.

 - Ian


> 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

My understanding is that this should be "identified by". It seems to me
that just about everything is identifiable (questions of infinities
aside). In that case "SHOULD be identifiable" says very little.

> --
> 
> 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 

...but only "identify" in the Arch Doc.


> that feel like
> synonymous but probably have subtle differences in nuance.: "designate",
> "identify", "denote".
> 
> Do URI identify, denote, and/or designate?

Sounds like a rat-hole to me. I'd stick with the I in URI.

> --
> 
> 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.

For the moment, I'll leave as is.

> --
> 
> 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. 

Yes, so the preceding sentence says "the use of". The sentence that
follows should, too. [I'll fix.]

> 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.

How about:

  Clients can do something useful with the fragment identifier and the 
  SVG representation, since SVG defines fragment identifier 
  semantics. Clients should not be expected to do something useful with 
  the fragment identifier for the PNG or JPEG/JFIF representations 
  since those specifications do not define fragment identifier 
  semantics.

> --
> 
> 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'.

How about: 

 "Available operations depend on the formats and protocols that make use
 of URIs."

> --
> 
> 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...."

Another way of stating this is "and how to represent the resource" which
includes the choice of formats but also the information content of the
representation, the number of representations, the rate of change of
the representations, etc. [No change for now]

> --
> 
> 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

[No change for now]

> 
> --
> 
> 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."

I don't recall where this text came from and I don't have a reference.
Chris Lilley, do you have a recollection of this?

> --
> 
> 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

I believe they are not being used as synonyms. [No change for now
pending discussions.]

> --
> 
> 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...

e^i*pi + 1 = 0

> --
> 
> 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.

I don't think that this is a swipe at XSL-FO. I read this as:

 * XML enables people to create repurposable formats and in general XML
   formats are repurposable.

 * XSL-FO, being a final form format, is an exception to that general
   practice.

> --
> 
> 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

I changed this in the 15 July draft. Please check out the new text.

> 
> --
> 
> 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."

Ok.

> --
> 
> 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).

I intentionally have not said "Resources contain URIs" but rather 
"Representations contain URIs." I'd like to hear from others whether
saying "When one resource refers to another with a URI" is preferable.

> --
> 
> 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. 

[No change.]

> --
> 
> 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.

See above.

> --
> 
> 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.

Ok.

> --
> 
> 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.

Yes, fixed in the 15 July draft.

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

Ok.

> --
> 
> 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.

Added a more explicit note.

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

Yes.

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

Yes.

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

Yes.

-- 
Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
Tel:                     +1 718 260-9447

Received on Wednesday, 16 July 2003 20:19:59 UTC