LC Notes on Section 3

At some recent meeting, I took an action to review the last call
comments associated with Section 3 of WebArch and make some proposals.
This message is intended to discharge that action.

Looking through the annotated spec[1], in order:

issue parsia20: Drop definition of "on the Web"[2]

  I think the informal definition is still a good idea as it avoids
  the otherwise FAQ, why doesn't webarch define it.

  Proposal: amend the note to read "...network connectivity,etc.)
            or otherwise interact with it."

  That provides an out for tel: scheme URIs. I assert that URNs are
  already "on the web" by the existing informal definition as I can
  retrieve representations of (some of) them just fine.

issue kopecky2: 3.1 Reference or Identify?[3]

  We already say that URIs identify resources. It's just about the
  first thing in Section 2. Section 3.1, where this comment occurs
  is talking about dereferencing that URI to get a representation.

  Proposal: close without action.

issue klyne11: Change "will result" to "will necessarily result"[4]

  Proposal: accept the suggestion.

issue klyne12: Proposal to drop paragraph on inconsistent frag ids[5]

  I think the intend of the document is to say that it is an error
  if the fragids identify inconsistent secondary resources even if
  the error isn't detectable. If http://example.com/animal#foo sometimes
  returns a picture of a horse if my user agent understands SVG and
  returns a picture of a cow if it doesn't, that's an error. The good
  practice note that follows makes this clear, I think.

  Proposal: close without action.

issue schema4: [3.3 Good practice: Fragment Identifier Consistency][6]

  I'm inclined to agree with the spirit of the comment and have no
  specific proposal at the moment.

issue stickler8: Section 3.3.1, last para, last sentence: Nature of
secondary resource not known through URI[7]

  I'm not sure what to do about this comment. When I read the sentence
  in question: "Parties that draw conclusions about the interpretation
  of a fragment identifier without retrieving a representation do so
  at their own risk; such interpretations are not authoritative." it
  seems perfectly straightforward to me.

  If I see http://example.com/building.svg#myOffice and (without
  dereferencing it) infer that it identifies the location of my office
  within some larger SVG diagram of my building, I do so at my own
  risk. If, on the other hand, I dereference it and get back an
  application/svg+xml document that contains something labelled "myOffice"
  then that's an authoritative interpretation.

  Stickler says:

    One cannot infer the nature of any URI denoted resource based
    either on the URI *or* based on any representation obtained by
    dereferencing that URI, either directly, or for URI references
    with fragment identifiers, by first dereferencing the base URI
    and interpreting the fragment in terms of the MIME type of
    the returned represenatation.

  which is either about something subtle having to do with what
  "nature" of a URI means or it is a flat disagreement about what
  MIME types and fragment identifier specifications say.

  In neither case do I have a proposal.

issue stickler9: Good practice note on URIs without fragids?[8]

  I don't think there's any reason why the use of a fragment identifier
  should interfere with PUT or POST. Fragment identifiers are resolved
  on the client, so the client has the entire resource. If it changes
  the resource, it can PUT or POST it. DELETE is a slightly more interesting
  case. For a secondary resource, it is probably going to make more sense
  to PUT or POST a modified version of the whole resource than to delete
  the whole thing, but I hope any user/application that's allowing DELETEs
  is smart enough to work that out.

  Proposal: suggest that the editor add an informal note along these lines

issue schema5: [3.3.1] Inconsistency with RFC2396bis about frag id meaning?[9]

  I don't see the contradiction. Webarch says:

    The Internet Media Type of the retrieved representation specifies
    the authoritative interpretation of the fragment identifier

  The quoted section of RFC2396bis says:

    The fragment's format and resolution is therefore dependent on the
    media type [RFC2046] of the retrieved representation

  Proposal: ask the commenter to clarify

issue msm12: WD-webarch-20031209, Section 3.3.1, para 1: Are there
constraints on the interpretation of fragment identifiers?[10]

  Proposal: The definer of the media type has total control over the
            interpretation of the fragment identifier. He or she
            can impose any constraints that they wish.

  (This comment is classified as an "error" but it seems merely to be
  a "question" to me.)

issue manola19: Please provide qualifying context about the nature of the Web[11]

  Manola raises an interesting point. While the authoritative interpretation
  of the URI can only be known by retrieving its representation and evaluating
  the fragment identifier in the context of that media type, it's certainly the
  case that other specs, like RDF/OWL, provide mechanisms to make assertions
  about the URI independent of its authoritative interpretation.

  Proposal: I think we should clarify this by adding an example along the
  lines that Manola outlines and discussing the distinction between the
  authoritative interpretation and the possibly trustable assertions made
  by RDF/OWL. Maybe we need a good practice note along the lines of: don't
  make these contradictory.

More to come...
                                        Be seeing you,
                                          norm

[1] http://www.w3.org/2001/tag/2003/lc1209/webarchWithIssues.html
[2] http://www.w3.org/2001/tag/2003/lc1209/issues.html#parsia20
[3] http://www.w3.org/2001/tag/2003/lc1209/issues.html#kopecky2
[4] http://www.w3.org/2001/tag/2003/lc1209/issues.html#klyne11
[5] http://www.w3.org/2001/tag/2003/lc1209/issues.html#klyne12
[6] http://www.w3.org/2001/tag/2003/lc1209/issues.html#schema4
[7] http://www.w3.org/2001/tag/2003/lc1209/issues.html#stickler8
[8] http://www.w3.org/2001/tag/2003/lc1209/issues.html#stickler9
[9] http://www.w3.org/2001/tag/2003/lc1209/issues.html#schema5
[10] http://www.w3.org/2001/tag/2003/lc1209/issues.html#msm12
[11] http://www.w3.org/2001/tag/2003/lc1209/issues.html#manola19

-- 
Norman.Walsh@Sun.COM / XML Standards Architect / Sun Microsystems, Inc.
NOTICE: This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.