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 08:46:16 UTC