RE: Arch Doc: 26 September 2003 Editor's Draft

Hello Ian,


> -----Original Message-----
> From: Ian B. Jacobs [mailto:ij@w3.org] 
> Sent: 26 September 2003 21:06
> To: www-tag@w3.org
> Subject: Arch Doc: 26 September 2003 Editor's Draft

<snip/>

> ==========================================================
> 
> Comments from Stuart 
> http://lists.w3.org/Archives/Public/www-tag/2003Sep/0128.html
> 
> 

<snip/>

> 2) Endnote 2 requires clarification. This is based on text
>    from Roy.
> 
>     "User agent configurations are usually defined by URI scheme,
>     with exceptions defined by further substring matches within
>     the URI."
> 
>     http://lists.w3.org/Archives/Member/tag/2003Jul/0079

Ok... I think I see the disconnect. The text at EndNote 2 says "User agent
configurations are usually defined by URI scheme, with exceptions defined by
further substring matches within the URI." But I do not see and would not
expect to see any user agent configurations defined by a URI scheme
(specification). I think what Roy was saying that such configuration as a UA
may allow is often available on a per-URI scheme basis. If that is the case
then a simple rewording will suffice... that said, I also don't think it
adds much to the document and would be happy to see the endnote dropped from
the document.

> 
> 3) Endnote three and use of other protocols than HTTP for
>    http URIs. Reference RFC 2396, section 1.2:
> 
>     "Although many URL schemes are named after protocols, this
>     does not imply that the only way to access the URL's resource
>     is via the named protocol.  Gateways, proxies, caches, and
>     name resolution services might be used to access some
>     resources, independent of the protocol of their origin, and
>     the resolution of some URL may require the use of more than
>     one protocol (e.g., both DNS and HTTP are typically used to
>     access an "http" URL's resource when it can't be found in a
>     local cache)."
> 
> Proposal: Added reference.

I see no added reference!

> 4) Cause/effect backwards in describing "link".
> 
>    I must be missing a subtle point. I don't know how (in the
>    Web arch) to detect that two resources are linked until
>    a URI ref appears in a representation.

[NB this was tagged picky]

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

A strict reading of this suggest that a link between resources if formed
only when (after) a reference has been made in a representation ie. implies
that two resources cannnot be linked even if a representation of the
refering resource has never been minted or exchanged. It seems to me that
the reason a representation might reference another resource is because the
resources are linked rather than the resources are linked because a
representation of one make reference to the other.

> 5) 2.4.1 Secondary Resources...
> 
>   SW: "Knowledge of the media-type associated with a frag-id is
>   implicit in the account given here. This seems to be at odds
>   with the use of URI references as opaque identifiers as
>   typified in RDF/Semantic Web. ie. we only give an account here
>   of the use of fragment ids in relation to a representation with
>   a known media-type"
> 
>   IJ: Does the following sentence which appears in the next
>       paragraph suffice?
> 
>     "The presence of a fragment identifier agent in a URI does
>     not imply that a retrieval action will take place."
> 
>   Or, from [URI]:
> 
>     "As with any URI, use of a fragment identifier component does
>     not imply that a retrieval action will take place. A URI with
>     a fragment identifier may be used to refer to the secondary
>     resource without any implication that the primary resource is
>     accessible. However, if that URI is used in a context that
>     does call for retrieval and is not a same-document reference
>     (section 4.4), the fragment identifier is only valid as a
>     reference if a retrieval action on the primary resource
>     succeeds and results in a representation for which the
>     fragment identifier is meaningful."

Hmmmm don't know... will think some more.

<snip/>

> 7) Good Practice Note: Content Negotiation With Fragments.
> 
>    SW: I prefer the wording of the Good practice note "Content
>    negotiation with fragments" from the current TR page draft:
>    http://www.w3.org/TR/2003/WD-webarch-20030627/#http-conneg-frag
> 
> 8) 2.5.2
> 
>    SW: Step 5&6 refer to "Content-type field": s/field/header/
> 
>    Looking at RFC2616, I find, for example in 9.2:
> 
>      "If the OPTIONS request includes an entity-body (as
>      indicated by the presence of Content-Length or
>      Transfer-Encoding), then the media type MUST be indicated by
>      a Content-Type field."
> 
>   No change.

Ok... 

> 9) 2.6 Persistence and Ambiguity
> 
>   No text proposed; no change.

Ok... but I trust that the issues raised by the comment remain open for
discussion.

>
> 10) 4.5 Binary and Textual Data Formats
> 
>   SW: "I wonder if some of the current discussion re text/*+xml
>   and application/*+xml should be reflected here. The bias in 4.5
>   is to promote XML as textual data format, so perhaps some
>   careful words are in order around the TAG disposition wrt
>   text/*+xml. Maybe a forward reference to 4.10.6 would cover
>   some of this."
> 
>   There is a forward ref in first sentence. Not sure what else
>   to add before more discussion in TAG.

The forward reference is to 4.10 as a whole (or maybe just to the header for
4.10 - never can tell the difference :-)).

The points was that in the current discussion, if I have kept upto date,
there is a move toward deprecation of text/*+xml. This seems somewhat ironic
when juxtaposed with encouragement to use XML because of its textual nature.
Maybe we have to let the dust of that thread of discussion settle out.

<snip content="responses to others"/>

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

Thanks,

Stuart
--

Received on Monday, 29 September 2003 11:43:51 UTC