RE: Resend: Comments on "Architecture of the World Wide Web, Firs t Edition"

Hello Patrick,

Your original posting is there and present in the archive at [1]. The
organisation of the archive may be confusing. We asked that it be divided
into quarters rather than months. The initial messages we received are
organised by month, and more recent ones have fallen in the by quarter
bucket - which despite being labelled Jan-March 2004 only contains messages
posted on or after 1st March.

Best regards

Stuart
--
[1]
http://lists.w3.org/Archives/Public/public-webarch-comments/2004Feb/0000.htm
l

> -----Original Message-----
> From: public-webarch-comments-request@w3.org 
> [mailto:public-webarch-comments-request@w3.org] On Behalf Of 
> Patrick Stickler
> Sent: 18 March 2004 13:47
> To: public-webarch-comments@w3.org
> Subject: Resend: Comments on "Architecture of the World Wide 
> Web, First Edition"
> 
> 
> 
> These comments were originally sent in early February, but I 
> could not find them in the archive for 
> public-webarch-comments@w3.org so I am resending them.
> 
> Patrick
> 
> 
> Begin forwarded message:
> 
> > From: Patrick Stickler <patrick.stickler@nokia.com>
> > Date: February 03, 2004 13:42:06 EET
> > To: public-webarch-comments@w3.org
> > Subject: Comments on "Architecture of the World Wide Web, First 
> > Edition"
> >
> >
> > I applaud the TAG for their efforts in bringing this document to 
> > maturity. Overall, I find it to be clear and consistent, 
> and its value 
> > to the future evolution of the web and semantic web will surely be 
> > immense.
> >
> > That said, I have some general comments on this final revision, and 
> > unfortunately, also a few non-trivial objections to how some 
> > particular topics are addressed.
> >
> > I hope that the TAG will find this input to be constructive 
> and useful.
> >
> > --
> >
> > Section 2.1, para 11, "Applications may apply rules...":
> >
> > Consider adding example of acceptable presumption of 
> equivalence when 
> > case distinctions exist only for web authority. E.g.
> >
> > "http://Weather.Example.Com/Oaxaca" = 
> > "http://weather.example.com/Oaxaca"
> >
> > but not necessarily
> >
> > "http://weather.example.com/Oaxaca" = 
> > "http://weather.example.com/oaxaca"
> >
> > --
> >
> > Section 2.3, last para:
> >
> > Consider adding example of URI ambiguity which illustrates 
> the problem.
> > E.g. if the same URI is used to denote two distinct resources, then 
> > when statements are made using that URI, it is unclear 
> which resource 
> > is meant, resulting in confusion and potentially undesirable side 
> > effects.
> >
> > --
> >
> > Section 2.3, last sentence:
> >
> > Correct "URI ambiguity arises a URI is used..." to "URI ambiguity 
> > arises _when_ a URI is used...".
> >
> > Also, consider adding a link from "Web resources" at end of 
> sentence 
> > to the informal note at the end of section 3 -- as this is 
> the first 
> > time that term occurs in the document, and this is quite a central 
> > term (even if informal). Possibly even consider adding the 
> term to the 
> > list of terms in section 5.
> >
> > --
> >
> > Section 3.1, para 1:
> >
> > Consider changing text to "...  Access may take many forms, 
> including 
> > retrieving a representation of the state of the resource (for 
> > instance, by using HTTP GET or HEAD), adding or modifying a 
> > representation of the state of the resource (for instance, by using 
> > HTTP POST or PUT, which in some cases may change the actual 
> state of 
> > the resource if the submitted representations are interpreted as 
> > instructions to that affect), and deleting some or all 
> representations 
> > of the state of the resource (for instance, by using HTTP DELETE, 
> > which in some cases may result in the deletion of the 
> resource itself)."
> >
> > --
> >
> > Section 3.2, para 1, last sentence:
> >
> > Consider changing to "A message may even include metadata about the 
> > message itself (for message-integrity checks, for instance).
> >
> > --
> >
> > Section 3.3.1, para 2:
> >
> > Para 2 does not seem quite correct.
> >
> > In order to know the authoritative interpretation of a fragment 
> > identifier, one does not dereference the entire URI 
> *containing* the 
> > fragment identifier, but must first obtain a different URI by 
> > truncating the fragment identifier, dereference that different URI, 
> > and based on the MIME type of the representation returned (if any) 
> > interpret the fragment identifier.
> >
> > It may be the case that certain clients, such as browsers, perform 
> > that fragment identifier truncation automatically -- but 
> that is not 
> > the same as actually dereferencing the *complete* URI 
> reference with 
> > fragment identifier.
> >
> > Granted, paragraph 3 seems to get it right, but the language of 
> > paragraph 2 does not read correctly to me.
> >
> > Question: are the methods PUT, POST or DELETE meaningful for URI 
> > references with fragment identifiers, in terms of 
> interacting with the 
> > state of the secondary resources denoted? If not, then it 
> seems there 
> > is a good principle that one should use URIs without fragment 
> > identifiers whenever possible to maximise the utililty of 
> those URIs.
> >
> > --
> >
> > Section 3.3.1, last para, last sentence:
> >
> > This sentence seems misleading, as if one can infer something about 
> > the nature of a secondary resource by interpreting a URI reference 
> > with fragement identifier.
> >
> > 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.
> >
> > This last sentence could either be removed or clarified/reworked.
> >
> > --
> >
> > Section 3.4, para 1:
> >
> > Consider changing "...parties can identify and communicate 
> about a Web 
> > resource." to simply "...parties can identify and 
> communicate about a 
> > resource.".
> >
> > Or then, again, link "Web resource" to a definition of that term.
> >
> > --
> >
> > Section 3.4, para 1, last sentence:
> >
> > The phrase "authoritative interpretation of representations of the 
> > resource" is a bit unclear. The owner of the URI can specify the 
> > denotation of the URI and what representations of that resource are 
> > accessible, but is it not the case that the MIME type 
> specifications 
> > define the interpretation of any given representation -- insofar as 
> > the web architecture is concerned?
> >
> > I.e., for a given representation, it is the MIME type specification 
> > that defines the interpretation of that representation, not 
> the owner 
> > of the URI denoting the represented resource. ???
> >
> > --
> >
> > Section 3.4, para 2:
> >
> > The text of this paragraph is a bit too strong regarding 
> URI owner's 
> > rights.
> >
> > The owner of a URI has the right to decide which representations of 
> > the denoted resource are accessible via that URI -- but in 
> fact anyone 
> > has the license to create a representation of that resource, and 
> > indirectly associate that representation via another URI that is 
> > declared (e.g. using own:sameAs) as semantically equivalent.
> > I.e. the rights of the owner of a URI are limited to the access of 
> > representations via that particular URI, not (necessarily) to total 
> > control of the resource denoted as well as any and all 
> representations 
> > of that resource (accessible via other URIs).
> >
> > --
> >
> > Section 3.5.1:
> >
> > Para 3 seems to contradict the last statement of para 1. In 
> para 1 it 
> > is said that POST requests and responses cannot be 
> referenced by URIs, 
> > yet para 3 describes a means to do just that.
> >
> > It seems that what is meant to be said in para 1 is that, per the 
> > default behavior of POST, the request and response are not normally 
> > assigned distinct URIs by which they can be later referenced. ???
> >
> > --
> >
> > Section 3.6, para 1:
> >
> > How can "...they both conclude that the resource is unreliable"
> > since (a) they cannot determine from either the URI or any 
> > representation what resource the URI actually denotes, and
> > (b) the behavior of a given server providing access to 
> representations 
> > of a resource is all that can be unreliable.
> > The resource itself is (typically) not part of the system.
> >
> > For all Nadia and Dirk know, the URI actually denotes the 
> union of the 
> > weather for Oaxaca and the #1 insurance company in Oaxaca -- and 
> > getting representations reflecting either of those facets of the 
> > resource ar perfectly acceptable, and *consistent* with the 
> nature of 
> > the resource denoted.
> >
> > A better example of "unreliability" might be a service which 
> > frequently returns 404 responses rather than useful 
> representations or 
> > one which often returns representations which do not accurately 
> > reflect the state of the weather in Oaxaca, or one which sometimes 
> > returns XHTML but other times returns plain text. Yet in 
> such cases, 
> > it is the service resolving the URI to representations that is 
> > unreliable or inconsistent, not the resource itself.
> >
> > --
> >
> > Section 3.2.1:
> >
> > Is it really nessessary to posit this good practice? The SHOULD 
> > suggests that owners of URIs who don't provide 
> representations of the 
> > denoted resources (either initially, or ever) are not 
> "doing the right 
> > thing".
> >
> > This issue has been under recent discussion relating to the info:
> > URI scheme -- where there are many organizations not (presently) 
> > prepared to provide representations for term resources 
> which could be 
> > denoted using http: URIs rather than creating the new
> > info: URI scheme -- yet failure to provide representations 
> for those 
> > terms (even if temporarily) is not really bad practice.
> >
> > And encouraging folks to mint http: URIs to denote resources which 
> > initially will not have representations, facilitates providing 
> > representations at a later date without impacting the use of those 
> > URIs as identifiers.
> >
> > Owners of URIs should be free to decide whether any representations 
> > are made available, and should *NOT* feel obligated to provide 
> > representations if they themselves have no need to do so. 
> URIs without 
> > representations may simply be less valueable/useful than those with 
> > representations. But it shouldn't be considered bad practice to not 
> > provide any representations.
> >
> > I recommend that this particular "good practice" be removed, even 
> > though language should remain which reflects that URIs with 
> accessible 
> > representations are usually more useful than those without.
> >
> > --
> >
> > Section 4.3, para 1, 2nd sentence:
> >
> > Consider changing "cell phones" to "mobile phones", consistent with 
> > subsequent paragraphs.
> >
> > --
> >
> > Section 4.5.4:
> >
> > I see alot of problems in this section... sorry.
> >
> > I do not see the necessity to introduce the concept of a "namespace 
> > document" into this particular publication. If a given URI does in 
> > fact denote a "namespace" resource, and that URI can be 
> dereferenced 
> > to obtain a representation, then that representation is a 
> > representation of the namespace. Period. Nothing more need 
> be said. No 
> > special kind of representation need be highlighted here.
> >
> > Furthermore, because *any* URI may be used as a namespace name, and 
> > XML Namespaces imposes *no* requirements that the URI used as a 
> > namespace name actually denote a "namespace" resource (it 
> might very 
> > well denote the concept of 'slightly watery fudge pudding') the 
> > language in this section suggests (incorrectly so) that (a) 
> users may 
> > presume that URIs used as namespace names denote "namespace" 
> > resources, and therefore (b) if a URI used as a namespace name is 
> > dereferencable to a representation, that representation 
> will describe 
> > the namespace in question. Both are false and will result 
> in confusion.
> >
> > [the definition of 'namespace document' in section 5 is 
> simply false]
> >
> > The TAG should significantly rework this section, stressing 
> the fact 
> > that the interpretation by an XML processor of a URI used as a 
> > namespace name (i.e. used as syntactic punctuation) should 
> be presumed 
> > to be disjunct from the interpretation of that URI as a resource 
> > identifier in the broader web context.
> >
> > None of the web-significant meaning of URIs when used as namespace 
> > names need have any relevance whatsoever to the terms grounded in 
> > those namespaces nor to the models or vocabularies employing those 
> > terms.
> >
> > It is incorrect to suggest that there is any semantic 
> relation between 
> > the meaning of a URI used as a namespace name and the 
> meaning of terms 
> > grounded in that namespace.
> >
> > Per the good practices "QNames indistinguishable from URIs" 
> and "QName 
> > mapping", what counts is the URI denoting the term -- and 
> discovery of 
> > knowledge about that term, vocabularies to which the term belongs, 
> > models employing that term, schemas for validating proper usage of 
> > that term, style sheets defining visual presentation per that term, 
> > etc. should begin with the term URI *alone*. The namespace name has 
> > *no* semantic significance whatsoever to the meaning and intended 
> > usage of that term.
> >
> > Namespace names are syntactic machinery introduced solely so that 
> > folks wouldn't have to use full URIs as element and attribute names.
> > Semantically,
> > they are no different from entities. The Web would have been far 
> > better off if syntax such as <&dc;title> would have been adopted 
> > rather than namespace names and prefixes -- yet the result is the 
> > same: the contraction of URIs to managable aliases.
> >
> > It is disappointing to see the TAG continuing to promote 
> the idea that 
> > any semantics associated with a URI used as a namespace 
> name has any 
> > relation whatsoever to the semantics of terms grounded in that 
> > namespace.
> >
> > --
> >
> > Section 5:
> >
> > Consider adding the term "Web resource" with a definition 
> such as "A 
> > resource identified by a web-dereferencable URI".
> >
> > --
> >
> > Section 5: Dereference a URI:
> >
> > Consider expanding to "Indirectly access the resource identified by 
> > the URI via a representation of that resource."
> >
> > --
> >
> > Section 5: Namespace document:
> >
> > Strongly advise the removal of both this term from the publication 
> > entirely but particularly this incorrect definition (see discussion 
> > above). The assertion that every URI used as a namespace 
> name denotes 
> > a namespace document is false.
> >
> > --
> >
> > Section 5: Secondary resource:
> >
> > This definition is difficult to read and seems to be 
> gramatically ill 
> > formed. It should be reworked a bit. Perhaps "A resource that is 
> > indicated by a fragment identifier component of a URI 
> reference, which 
> > must be interpreted in terms of a representation obtained by 
> > dereferencing the base URI of the URI reference along with 
> the media 
> > type of that representation". ???
> >
> > --
> >
> > End of comments...
> >
> >
> >
> > Regards,
> >
> > Patrick
> >
> >
> > --
> >
> > Patrick Stickler
> > Nokia, Finland
> > patrick.stickler@nokia.com
> >
> >
> 
> --
> 
> Patrick Stickler
> Nokia, Finland
> patrick.stickler@nokia.com
>

Received on Thursday, 18 March 2004 11:26:50 UTC