TAG Issues List for Last Call of 9 December 2003 Webarch

hammond1: Distinguish normative/informative references? [link to this issue]

Would it be appropriate to distingush between normative and non-normative
(i.e. informative) references? 

Editorial concerning

6. References

Discussion history

9 Feb 2004

Transition history

raised on 10 Dec 2003 by Hammond, Tony (ELSLON) (T.Hammond@elsevier.com)

declined on 9 Feb 2004

The TAG does not feel an informative/normative split is justified.

Acknowledgment cycle

Not started

Action history

hammond2: Editorial comments [link to this issue]

The reviewer made a number of editorial suggestions.

Discussion history

9 Feb 2004

Transition history

raised on 11 Dec 2003 by Hammond, Tony (ELSLON) (T.Hammond@elsevier.com)

Action history

harold1: Title of URI uniqueness constraint [link to this issue]

"Constraint: URI uniqueness" is defined:

Web architecture does not constrain a Web resource to be identified 
by a single URI.

The constraint and the title do not seem to match. Perhaps the title is supposed to be "URI non-uniqueness" or perhaps the text is supposed to be something like "Each URI identifies exactly one resource". However, the title suggests to me that URIs are unique, and the text suggests the opposite.

Editorial concerning

2.1. URI Comparisons

Transition history

raised on 10 Dec 2003 by Elliotte Rusty Harold (elharo@metalab.unc.edu)

agreed on 12 May 2004

At their 12 May 2004 TAG teleconference, the TAG resolved to demote the first constraint of section 2.1 to a sentence.

Acknowledgment cycle

announced by group on 27 May 2004

Action history

karr1: What does "authority component" mean? [link to this issue]

In section 2.1, "URI Comparisons", I understand the meaning of the paragraph which begins "Applications may apply rules ...". It means that if your application makes assumptions about URI equivalences based on details not covered in the specification, then it's your responsibility if any problems develop from that. What I don't understand is the term "authority component" in this sentence:

For example, for "http" URIs, the authority component is case-insensitive.

Clarification concerning

2.1. URI Comparisons

Transition history

raised on 21 Dec 2003 by David M. Karr (dmkarr@earthlink.net)

agreed on 14 May 2004

The TAG agreed with the Editor's change to include parenthetical.

Acknowledgment cycle

announced by group on 27 May 2004

Action history

ducharme1: Editorial comments [link to this issue]

The reviewer made a number of editorial suggestions.

Discussion history

9 Feb 2004

Transition history

raised on 29 Dec 2003 by DuCharme, Bob (LNG-CHO) (bob.ducharme@lexisnexis.com)

agreed on 9 Feb 2004

The Editor will take these comments into account.

Acknowledgment cycle

Not started

Action history

worthington1: Simplify the text and separate the W3C politics [link to this issue]

Split document in two: architecture, rationale

Discussion history

9 Feb 2004

Transition history

raised on 29 Dec 2003 by Tom Worthington (tomw99@fastmail.fm)

declined on 9 Feb 2004

The TAG believes the document has an appropriate quantity/level of examples. However, the reviewer has said: "Thanks, I am satisfied that you have given my comment serious consideration. But as is I don't see the document as being workable, so I will not be recommending use of the Architecture to my students, colleagues or clients."

Acknowledgment cycle

Not started

Action history

booth1: Definition of "Web Agent" [link to this issue]

Should not include people

Editorial concerning

1. Introduction

Discussion history

9 Feb 2004

Transition history

raised on 6 Jan 2004 by David Booth (dbooth@w3.org)

declined on 9 Feb 2004

The TAG defends its definition of "agent" as including people.

Acknowledgment cycle

announced by group on 10 May 2004

agreement by reviewer on 11 May 2004

Does not object to the definition

Action history

booth2: What rights does "URI ownership" confer? [link to this issue]

Following the lessons of the "deep linking" debacle, it might be good to 
say explicitly what rights "URI ownership" does or does not confer.  This 
is somewhat addressed later, but it might be good to say something in this 
section.

Clarification concerning

2.2. URI Ownership

Discussion history

9 Feb 2004

Transition history

raised on 6 Jan 2004 by David Booth (dbooth@w3.org)

agreed on 9 Feb 2004

The Editor will include a forward link from 2.2 to 3.6.3.

Acknowledgment cycle

announced by group on 10 May 2004

agreement by reviewer on 11 May 2004

Satisfied with editorial change in 10 May 2004 draft.

Action history

booth3: 4.5.4: NS document as definitive source of info on namespace [link to this issue]

However, the term "definitive" is missing.  Was this intentional?  Based on 
a quick skimming of the issue, it looks like the TAG is in agreement that 
the namespace document should directly or indirectly provide *definitive* 
material about the namespace, but I'm not sure.

Clarification concerning

4.5.4. Namespace Documents

Discussion history

9 Feb 2004, 22 Mar 2004, 14 May 2004

Transition history

raised on 20 Feb 2004 by David Booth (dbooth@w3.org)

agreed on 22 Mar 2004

The TAG agrees but for consistency prefers the term "authoritative".

Acknowledgment cycle

announced by group on 10 May 2004

agreement by reviewer on 11 May 2004

Satisfied with editorial change in 10 May 2004 draft.

Action history

goodwin1: Editorial suggestions [link to this issue]

The reviewer made a number of useful
editorial suggestions.

Discussion history

9 Feb 2004

Transition history

raised on 7 Jan 2004 by Tim Goodwin (tjg@star.le.ac.uk)

agreed on 9 Feb 2004

The Editor will take these comments into account.

Acknowledgment cycle

Not started

Action history

stickler1: Editorial suggestions [link to this issue]

The reviewer made a number of useful editorial suggestions. This
issue addresses those editorial 
points in the initial email not covered by other
issues.

Editorial concerning

4.5.4. Namespace Documents

Transition history

raised on 3 Feb 2004 by Patrick Stickler (patrick.stickler@nokia.com)

Action history

stickler2: Sections 4.5.4, 5: Namespace document [link to this issue]

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

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.

Discussion history

9 Feb 2004, 2 Mar 2004, 12 May 2004

Transition history

raised on 3 Feb 2004 by Patrick Stickler (patrick.stickler@nokia.com)

declined on 9 Feb 2004

Adopt the following definition as a substitute for namespace document: "If a namespace declaration binds a prefix to a URI, and that URI can be dereferenced to get a representation, then that is a namespace representation."

Acknowledgment cycle

announced by group on 27 May 2004

Action history

stickler3: Section 5: Dereference a URI [link to this issue]

Consider expanding to "Indirectly access the resource identified by
the URI via a representation of that resource."

Editorial concerning

5. Term Index

Discussion history

14 May 2004

Transition history

raised on 3 Feb 2004 by Patrick Stickler (patrick.stickler@nokia.com)

declined on 14 May 2004

The definition makes sense in the full context of the document; the TAG recommended no change to the glossary.

Acknowledgment cycle

Not started

Action history

stickler4: Section 3.6.1 Proposed removal of good practice note [link to this issue]

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.

Request concerning

3.6.1. Representation availability

Discussion history

12 May 2004

Transition history

raised on 3 Feb 2004 by Patrick Stickler (patrick.stickler@nokia.com)

declined on 12 May 2004

The TAG intended to indicate that people SHOULD provide representations; the community is poorer where representations are not available. "SHOULD" allows URI owners to make a choice.

Acknowledgment cycle

announced by group on 27 May 2004

Action history

stickler5: Section 3.6, para 1: Fix "resource is unreliable" [link to this issue]

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.

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.

Error concerning

3.6. Representation Management

Discussion history

2 Mar 2004

Transition history

raised on 3 Feb 2004 by Patrick Stickler (patrick.stickler@nokia.com)

agreed on 2 Mar 2004

The Editor will s/unreliable/unpredictable.

Acknowledgment cycle

Not started

Action history

stickler6: Section 3.5.1: POST requests and URIs [link to this issue]

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

Error concerning

3.5.1. Unsafe Interactions and Accountability

Discussion history

2 Mar 2004

Transition history

raised on 3 Feb 2004 by Patrick Stickler (patrick.stickler@nokia.com)

agreed on 2 Mar 2004

The Editor will review 3.5.1 and propose a revision to the TAG that more clearly distinguishes the two topics of bookmarking results of POST and paper trails (both safe and unsafe contexts).

Acknowledgment cycle

announced by group on 27 May 2004

Action history

stickler7: Section 3.4, para 2: URI ownership questions [link to this issue]

The reviewer raised a number of points about URI ownership and authority in sections 3.4 para 1 and para 2.

Error concerning

• 3.4. Authoritative Representation Metadata
• 2.2. URI Ownership

Discussion history

9 Feb 2004

Transition history

raised on 3 Feb 2004 by Patrick Stickler (patrick.stickler@nokia.com)

Action history

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

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.

Clarification concerning

3.3.1. Media Types and Fragment Identifier Semantics

Discussion history

9 Feb 2004, 3 May 2004

Transition history

raised on 3 Feb 2004 by Patrick Stickler (patrick.stickler@nokia.com)

Action history

stickler9: Good practice note on URIs without fragids? [link to this issue]

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.

Proposal concerning

3.3.1. Media Types and Fragment Identifier Semantics

Discussion history

3 May 2004

Transition history

raised on 3 Feb 2004 by Patrick Stickler (patrick.stickler@nokia.com)

Subsumed by issue(s) on 19 Jul 2004

Overtaken by events.

Action history

stickler10: Section 5: Secondary resource [link to this issue]

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

Editorial concerning

5. Term Index

Transition history

raised on 3 Feb 2004 by Patrick Stickler (patrick.stickler@nokia.com)

Action history

pps1: Ownership and authority [link to this issue]

Given all these problems I don't see how the architectural principles of
the World Wide Web can be so dependent on resource ownership.  Many of the
uses of ``resource owner'' in the document do not make sense at all and
need to be removed from the document.

Error concerning

• 2.2. URI Ownership
• 3.4. Authoritative Representation Metadata

Discussion history

23 Feb 2004, 15 Mar 2004

Transition history

raised on 12 Feb 2004 by Peter F. Patel-Schneider (pfps@research.bell-labs.com)

agreed on 12 May 2004

The term "Resource owner" has been replaced with "URI owner".

Acknowledgment cycle

Not started

Action history

hawke1: Proposed good practice note on looking inside protocol interactions [link to this issue]

     Good practice: user agents should allow user to look "inside" to
     see (and even manipulate) the protocol interactions the agent is
     performing on behalf of the user.

Proposal concerning

1.2.4. Protocol-based Interoperability

Discussion history

12 May 2004

Transition history

raised on 13 Feb 2004 by Sandro Hawke (sandro@w3.org)

Subsumed by issue(s) on 19 Jul 2004

Overtaken by events.

Action history

hawke2: Section 2: Full agreement not required for communication [link to this issue]

Parties who wish to communicate must agree upon a shared set of identifiers and on their meanings.

This is untrue for some reasonable meanings of "meaning", as Pat Hayes has argued from time to time. You could say instead: "Parties who wish to communicate must agree on the practical effects of using certain identifiers." or "Parties who wish to communicate must agree upon a shared set of identifiers and (to a reasonable degree) on their meanings."

That is: some ambiguity of meaning is both reasonable and unavoidable. I don't think an unqualified "agree" normally means "partially agree".

Does http://weather.example.com/oaxaca identify the weather report for just Oaxaca or for the Oaxaca region? When it starts to matter, you can start to build a shared understanding of which it is. But you can't banish those ambiguities until you notice them. There's also a school of design where you choose not to banish them, even when you see them, until you know they matter.

Error concerning

2. Identification

Transition history

raised on 13 Feb 2004 by Sandro Hawke (sandro@w3.org)

Subsumed by issue(s) on 19 Jul 2004

Overtaken by events.

Action history

hawke3: 2.2 UUID/MD5 not registered URI schemes [link to this issue]

They are not on IANA's list.  I pay
some attention, and I'm not aware of a stable specification for either
one.   The spec on DanC's list for UUID has long since expired; the
reference for MD5 is simply to a hypothetical use of it.

Editorial concerning

2.2. URI Ownership

Discussion history

7 Jun 2004

Transition history

raised on 13 Feb 2004 by Sandro Hawke (sandro@w3.org)

Action history

hawke4: 2.3: Propose "URI overloading" not "URI ambiguity" [link to this issue]

Well then use a different word!   Please!   Call it "URI Overloading"
and let "URI Ambiguity" be used for the unavoidable and quite
acceptable situation I talked about in my Comment 8.

Editorial concerning

2.3. URI Ambiguity

Transition history

raised on 13 Feb 2004 by Sandro Hawke (sandro@w3.org)

agreed on 12 May 2004

The TAG accepted the global change of "URI ambiguity" to "URI Overloading".

Acknowledgment cycle

Not started

Action history

hawke6: 2.6. Fragment Identifiers: "Stem resource" [link to this issue]

I would suggest instead [of "secondary resource"] that you:

     (1) Name the the portion of the URI up the the "#".  TimBL has
         called this the "racine", but I like "stem", "trunk", or
         maybe even "non-fragment portion".
     (2) Call the resource identified by a URI's stem the "stem
         resource", or something like that.

Editorial concerning

2.6. Fragment Identifiers

Discussion history

7 Jun 2004

Transition history

raised on 13 Feb 2004 by Sandro Hawke (sandro@w3.org)

hawke7: 2.7.2. Assertion that Two URIs Identify the Same Resource [link to this issue]

Proposal" Knowing two URIs identify the same resource does not, however,
    mean they are interchangeable.  For example, Oaxaca might have
    several government-run weather stations, and the measurements take
    from each of these might be available from both
    weather.example.org and weather.example.com.

    The first might call a particular station
        http://weather.example.org/stations/oaxaca#ws17a
    while the second calls it 
        http://weather.example.com/rdfdump?region=oaxaca&station=ws17a

    These two URIs would both identify the same resource, a certain
    collection of weather measuring equipment.  They are owl:sameAs
    each other.  But an attempt to dereference them might well produce
    different content produced by different organizations (probably
    based originally on the same government-supplied data), so a user
    agent which substituted one for the other would be serving its
    user poorly.

Proposal concerning

2.7.2. Assertion that Two URIs Identify the Same Resource

Discussion history

7 Jun 2004

Transition history

raised on 13 Feb 2004 by Sandro Hawke (sandro@w3.org)

Subsumed by issue(s) on 19 Jul 2004

Overtaken by events.

Action history

hawke8: 3.2. Messages and Representations: Use of "state" [link to this issue]

Does "state" really mean anything there?  Is there a difference
between "data about Ian" and "data about the state of Ian"?  Maybe
this could be clarified with:

   Note: the phrases "representation of the state of the resource" and
   "representation of the resource" mean essentially the same thing;
   the term "state" is sometimes used to help convey that resources
   and thus their representations often vary over time.

Editorial concerning

3.2. Messages and Representations

Transition history

raised on 13 Feb 2004 by Sandro Hawke (sandro@w3.org)

Action history

hawke9: 3.2. Messages and Representations [link to this issue]

s/electronic data/data

Transition history

raised on 13 Feb 2004 by Sandro Hawke (sandro@w3.org)

Action history

hawke10: 3.5. Safe Interactions [link to this issue]

Choice of word "safe" in "safe operation" and relation to "dangerous"

Editorial concerning

3.5. Safe Interactions

Transition history

raised on 13 Feb 2004 by Sandro Hawke (sandro@w3.org)

declined on 13 May 2004

The TAG agreed with the Editor's choice to retain the words "safe" and "unsafe".

Acknowledgment cycle

Not started

Action history

dhm1: 1.1.3. Principles, constraints and good practices [link to this issue]

The document defines design choices and properties but never uses them. Are they needed at all, then? The document has 2 constraints, but its not clear they fit in the given definition. (See related comments from Martin Dürst about the terms principle/constraint/etc.

Editorial concerning

1.1.3. Principles, Constraints, and Good Practice

Transition history

raised on 17 Feb 2004 by Dominique Hazaël-Massieux (dom@w3.org)

Action history

dhm2: "Silent recovery from error is harmful" [link to this issue]

The formulation of the principle loses most of the context; what about
"User agents SHOULD NOT silently recover from errors" 

Editorial concerning

1.2.3. Error Handling

Transition history

raised on 17 Feb 2004 by Dominique Hazaël-Massieux (dom@w3.org)

Action history

dhm3: "Language extension" definition [link to this issue]

The language extension definition seems awkward in comparison with the
usual terminology; an extension to XSLT or SOAP or most languages I can
think of is used to designate the additional part of the language,
rather than the superset of the language including the basic language +
the additional part. That is, if A is the basic language, B, the
additional part, extensions usually refer to B rather than A+B.

Editorial concerning

1.2.2. Extensibility

Discussion history

12 May 2004

Transition history

raised on 17 Feb 2004 by Dominique Hazaël-Massieux (dom@w3.org)

agreed on 12 May 2004

The TAG agrees to change the definitions so where "Extended language" is used to mean "A+B", "Extension" is used to mean "B".

Acknowledgment cycle

announced by group on 27 May 2004

Action history

dhm4: 1.2.4 Protocol based interoperability [link to this issue]

The message of the section is not clear; "important interfaces are
defined in terms of protocols"... rather than?

Editorial concerning

1.2.4. Protocol-based Interoperability

Transition history

raised on 17 Feb 2004 by Dominique Hazaël-Massieux (dom@w3.org)

Action history

dhm5: 4.1 Prevalence of Unicode [link to this issue]

"In modern textual data formats, the characters are usually taken
from the Unicode repertoire"
Is that really the state of affair, or rather what modern textual
formats should do? It seems that the adjective "modern" is used to
suggest that it's what textual data formats should do to be modern,
rather than to describe the current reality.

Editorial concerning

4.1. Binary and Textual Data Formats

Transition history

raised on 17 Feb 2004 by Dominique Hazaël-Massieux (dom@w3.org)

Action history

dhm6: Use of "server" in "...authoritative server metadata..." [link to this issue]

Should this be reworded in  "User agents MUST NOT silently ignore
authoritative metadata."? If so, is it still worth mentioning? (ie, is
there any point in saying "do what the protocol says to do"?)

Clarification concerning

3.4.1. Inconsistencies between Metadata and Representation Data

Transition history

raised on 20 Feb 2004 by Dominique Hazaël-Massieux (dom@w3.org)

Action history

dhm7: Webarch conformance model, subjects of GPNs [link to this issue]

(The reviewer analyzes the various subjects of the GPNs
and raises some questions.) "In any case, my general comment is that it would be better to reduce the
list of conformance subjects in the arch document:
- to avoid some of the fuzziness introduced by having non-defined
conformance subjects
- to make it easier for the reader to understand the requirements."

Transition history

raised on 20 Feb 2004 by Dominique Hazaël-Massieux (dom@w3.org)

Action history

weitzner1: Proposed summary format [link to this issue]

I would take the principle and put it together with the nice 1 sentence explanation. String together all principles, contraints, and good practices, with the explanatory material in the box, you'd have a very, short, accessible summary of the whole document.
My main interest in such a re-organization, is that many of the principles are stated as buzzwords. They mean a lot to people who already know them, but are pretty abstract otherwise. I think that this short overview of the content of the arch. document would help make what is a somewhat long document much more accessible and likely to be used.

Transition history

raised on 17 Feb 2004 by

Action history

rodriguez1: Dataweb?: XDI and XRI. [link to this issue]

I was reviewing the OASIS XRI (eXtensible Resource Identifier)
Specification [2], one of the components of the Dataweb model [1].  I'm
curious, if this new work affect in any way the *WebArch*?

Discussion history

12 May 2004

Transition history

raised on 20 Feb 2004 by Sergio Rodriguez (srodriguez@bdgsa.net)

declined on 12 May 2004

The TAG believes that there is no need to address this comment in the Architecture Document.

Acknowledgment cycle

announced by group on 27 May 2004

kopecky1: Proposed to drop stories [link to this issue]

Some of the "stories" in the document seem pointless to me, I suggest
dropping or expanding them: expand story in 2.6; story in 3.6 is too
unlikely and extreme, might be dropped; expand story in 3.6.3; expand or
drop story in 4.5.3.

Transition history

raised on 23 Feb 2004 by Jacek Kopecky (jacek.kopecky@systinet.com)

Action history

kopecky2: 3.1 Reference or Identify? [link to this issue]

Does a URI *reference* or identify a resource? Is there even a
difference? I'm unsure here, but the choice of words might cause
confusion.

Clarification concerning

3.1. Using a URI to Access a Resource

Discussion history

26 Apr 2004

Transition history

raised on 23 Feb 2004 by Jacek Kopecky (jacek.kopecky@systinet.com)

declined on 26 Apr 2004

The TAG believes that the document is sufficiently clear regarding reference/identify as is.

Acknowledgment cycle

Not started

Action history

kopecky3: 4 application/xml [link to this issue]

First para says "before inventing a new data format, designers should
carefully consider re-using one that is already available" but the whole
doc doesn't seem to say why all XML formats shouldn't be
application/xml.

Clarification concerning

4. Data Formats

Discussion history

13 May 2004

Transition history

raised on 23 Feb 2004 by Jacek Kopecky (jacek.kopecky@systinet.com)

Action history

kopecky4: 4.5.3 use of "understand" [link to this issue]

"Namespaces in XML provides a mechanism for establishing a
globally unique name that can be understood in any context." What does
it mean to understand a name? Should this say that the globally unique
name can unambiguously identify the intended meaning of the
element/attribute?

Clarification concerning

4.5.3. XML Namespaces

Transition history

raised on 23 Feb 2004 by Jacek Kopecky (jacek.kopecky@systinet.com)

Action history

kopecky5: 4.5.5 More info on qnames, fragids, ns docs [link to this issue]

Below the Good Practice: QName Mapping - the section (or some
other) should probably say more on the interaction of QName Mapping,
fragment identifiers in XML (4.5.8) commonly used for this mapping and
namespace documents (4.5.4)

Request concerning

4.5.5. QNames in XML

Discussion history

22 Mar 2004, 7 Jun 2004

Transition history

raised on 23 Feb 2004 by Jacek Kopecky (jacek.kopecky@systinet.com)

Subsumed by issue(s) on 19 Jul 2004

Overtaken by events.

Action history

kopecky6: 4.5.6 What's the conclusion? [link to this issue]

This section lacks a conclusion, any kind of statement on what
should/should not be used. Or words that at the moment there is no
conclusion.

Request concerning

4.5.6. XML ID Semantics

Discussion history

22 Mar 2004, 14 May 2004

Transition history

raised on 23 Feb 2004 by Jacek Kopecky (jacek.kopecky@systinet.com)

agreed on 22 Mar 2004

The TAG believes this is an open issue in Web architecture, which the Editor should highlight more in the text.

Acknowledgment cycle

Not started

Subsumed by issue(s) on 19 Jul 2004

Overtaken by events.

Action history

duerst1: Principle and constraint titles [link to this issue]

The headline should be worded so that it is easy to remember
     and says the right thing (rather than it's opposite)....

Transition history

raised on 23 Feb 2004 by Martin Duerst (duerst@w3.org)

Action history

duerst2: WebArch and RFC2396bis: URIs and Fragids [link to this issue]

3.3 Internet Media Type: Streamlining terminology.
For URIs, a clear distinction is made between Resource and Representation.
But when it comes to fragid, this distinction is suddenly gone,
without any explanations. (See email for more detail)

Discussion history

9 Feb 2004

Transition history

raised on 1 Mar 2004 by Martin Duerst (duerst@w3.org)

Action history

diwg1: Add scenario(s) with dynamically generated URI [link to this issue]

Scenarios appear to be based on "static"  URI's; i.e.:  "persistent" URI's (reference chapter 3.6.2).  Suggest discussion of "dynamically generated" URI's; particularly addressing situations where dynamic URI's are bookmarked or forwarded by a user.

Proposal concerning

3.6.2. URI Persistence

Discussion history

14 May 2004

Transition history

raised on 25 Feb 2004 by Aguilera, Augusto F (augusto.f.aguilera@boeing.com), on behalf of Device-Independence Working Group

Action history

diwg2: Don't communicate language info in URIs (in example) [link to this issue]

The statement  "one might reasonably create URI's that ..."  in the following passage may be inappropriate, as the preference for viewing a resource in Italian or Spanish should be communicated as meta information within the context, for which mechanisms such as CC/PP are being developed.  To countenance the use of non-unique URI's for such a purpose is unwise.

Error concerning

2.1. URI Comparisons

Discussion history

12 May 2004

Transition history

raised on 25 Feb 2004 by Aguilera, Augusto F (augusto.f.aguilera@boeing.com), on behalf of Device-Independence Working Group

declined on 12 May 2004

The TAG believes that it is useful to indicate that there are two resources (one Spanish and one Italian) but to add to the example some discussion of content negotiation.

Acknowledgment cycle

announced by group on 27 May 2004

Action history

diwg3: Suggest discussion of accessing different representations (transformed) of the same resource [link to this issue]

Suggest discussion of accessing different representations (i.e.:  transformed) of the same URI.  This relates to Device Independence Principles DIP-1 (Device Independent Access) and DIP-2 (Device Independent Web Page Identifiers).  Mention of HTTP Content Negotiation appears insufficient.

Transition history

raised on 25 Feb 2004 by Aguilera, Augusto F (augusto.f.aguilera@boeing.com), on behalf of Device-Independence Working Group

Action history

diwg4: Suggest discussion of the limitations of Internet media types as the prime mechanism for selecting between different representations of a resource. [link to this issue]

No version info in media types? Media type as special case of content negotiation?

Proposal concerning

4.2.1. Versioning

Discussion history

14 May 2004

Transition history

raised on 25 Feb 2004 by Aguilera, Augusto F (augusto.f.aguilera@boeing.com)

agreed on 14 May 2004

The TAG agrees that more needs to be stated about trade-offs. The TAG has created a new issue mediaTypeManagement-45.

Acknowledgment cycle

announced by group on 27 May 2004

Action history

clark1a: Fragment Identifier Semantics [link to this issue]

While I suspect that the older language for describing these semantics
had its own problems, I would be happier either with (1) its return or
(2) some further amplification or clarification of the existing
language.

Clarification concerning

2.6. Fragment Identifiers

Discussion history

14 May 2004

Transition history

raised on 26 Feb 2004 by Kendall Clark (kendall@monkeyfist.com)

agreed on 14 May 2004

• The answer to the reviewer's question is "yes to 1."
• The TAG believes that no change to the document is required.

Acknowledgment cycle

announced by group on 27 May 2004

Action history

clark1b: Conflicting secondary resources [link to this issue]

See writeup from KC.

Clarification concerning

2.6. Fragment Identifiers

Discussion history

14 May 2004

Transition history

raised on 26 Feb 2004 by Kendall Clark (kendall@monkeyfist.com)

clark2: What kinds of ambiguity are there? [link to this issue]

AWWW abjures URI ambiguity; but in trying to think carefully about this,
I've realized that it's important to distinguish two kinds of URI ambiguity:
diachronic and synchronic. The AWWW only addresses the former kind, and I
think it should address the latter kind, too. 
I'd like to see some language in the AWWW about avoiding synchronic
ambiguity by avoiding the "URI overloading" mistake with content
negotiation. 

Clarification concerning

2.3. URI Ambiguity

Transition history

raised on 26 Feb 2004 by Kendall Clark (kendall@monkeyfist.com)

clark3: Willy-Nilly Resource Change [link to this issue]

The AWWW says that one may conclude that agents or representations are
each referring to the same resource if they are using identical URIs.
But that's problematic; it suggests that the relation between
resources and URIs is in some sense timeless and static. Once a URI
has been coined to identify a given resource, it can only ever
identify precisely that resource; else, we have to embrace the
willy-nilly change problem.

Clarification concerning

2.1. URI Comparisons

Transition history

raised on 26 Feb 2004 by Kendall Clark (kendall@monkeyfist.com)

declined on 14 May 2004

The TAG believes the reviewer's question is addressed by section 3.6.2 of the document.

Acknowledgment cycle

announced by group on 27 May 2004

Action history

clark4a: Hypertext Good Practice Redundancies [link to this issue]

The first good practice says, in my paraphrase, that (1) good
representation types allow users to make links to other resources and to
parts of representation-states of resources.  The second good practice
says, again in my paraphrase, that (2) good representation types allow
users to make "Web-wide" links rather than merely "internal document"
links.

Aren't these redundant?

Clarification concerning

4.4. Hypertext

Discussion history

14 May 2004

Transition history

raised on 26 Feb 2004 by Kendall Clark (kendall@monkeyfist.com)

declined on 14 May 2004

The TAG believes that the statements say different things and both are justified.

Acknowledgment cycle

announced by group on 27 May 2004

clark4b: "Expected UI Paradigm"? [link to this issue]

Surely the AWWW also wants to say that for those kinds of web application or scenario -- Service Oriented Architecture and Semantic Web being the two obvious examples -- where hypertext is not the "expected user interface paradigm", by virtue of the fact that there really isn't a UI per se, one still wants to prefer representation types which allow users to make hypertext links between resources. REST and SOAP and RDF and WSDL and a lot of other fun stuff works precisely because -- even in the absence of any human-facing UI -- what's happening is that messages are being passed around between machines, some of which contain assertions about resources, and they are messages which contain hypertext links to other resources.

The real problem here is that there is no real formalization of "hypertext link" in the AWWW. If it means A-HREF links simpliciter, then my point about SOA and Semantic Web exceptions to this practice is unmotivated and null. But if, as seems likely from Section 4.5.2. Links in XML, "hypertext links" encompasses any link mechanism (that is, XLink and friends) whereby HTTP URIs identify resources with which agents may interact with the resources-states thereof, then something like my point is needed.

Clarification concerning

4.4. Hypertext

Transition history

raised on 26 Feb 2004 by Kendall Clark (kendall@monkeyfist.com)

Action history

clark5: Silent Error Recovery Always Harmful? [link to this issue]

I don't agree with the exceptionless form of this principle.  I think one
can imagine silent error recoveries which aren't harmful.  I suggested an
amended version: silent error recovery is harmful if, and only if, it does
some harm beyond mere failure to notify; or, put better: mere failure to
notify isn't always a harm. (I'd be just as happy with the smallest 
possible weakening of the principle, something like: "Silent recovery from 
error is usually [or "typically" or "often"] harmful."

Error concerning

1.2.3. Error Handling

Discussion history

9 Feb 2004

Transition history

raised on 26 Feb 2004 by Kendall Clark (kendall@monkeyfist.com)

agreed on 2 Mar 2004

The TAG believes that text from the approved finding "Authoritative Metadata" will address the reviewer's concerns. Henceforth, refer to issue dhm2.

Acknowledgment cycle

announced by group on 27 May 2004

Action history

clark6: Separating Presentation From Content [link to this issue]

This is often harder than the AWWW lets on, and sometimes it's simply not possible at all. I think the language should be modulated to reflect that reality; see xproposed text

Clarification concerning

4.3. Separation of Content, Presentation, and Interaction

Discussion history

14 May 2004

Transition history

raised on 26 Feb 2004 by Kendall Clark (kendall@monkeyfist.com)

Action history

clark7: More Ambiguity [link to this issue]

"the ambiguous use of terms" is ambiguous; and, contrary to the AWWW's
(fairly casual, of course) claim, ambiguity does *not* always impose a cost
in human communications -- a research result demonstrated by UK cognitive
scientists, among others.  (If you want the full cite to this paper on
CiteSeer, I can drum it up.)

Transition history

raised on 26 Feb 2004 by Kendall Clark (kendall@monkeyfist.com)

Action history

clark8: Section 3.4.'s Unmotivated Paragraph [link to this issue]

There is a paragraph about URI ownership in Section 3.4, and I can't understand what it's doing there. I would strike or amend it. Full discussion of this issue.

Transition history

raised on 26 Feb 2004 by Kendall Clark (kendall@monkeyfist.com)

Action history

clark9: "Safe" and "Unsafe" Interactions [link to this issue]

I really really hate the way this discussion is framed in the AWWW; see proposals.

Transition history

raised on 26 Feb 2004 by Kendall Clark (kendall@monkeyfist.com)

clark11: The "great power" of URIs and their "vastness of choice" [link to this issue]

I find this sentence, from Section 2. Identification, to be garbled at best; see discussion.

Transition history

raised on 26 Feb 2004 by Kendall Clark (kendall@monkeyfist.com)

Action history

clark12: Needless Propagation of URIs? [link to this issue]

I think this, as stated, is too strict; see further discussion.

Discussion history

9 Feb 2004

Transition history

raised on 26 Feb 2004 by Kendall Clark (kendall@monkeyfist.com)

agreed on 2 Mar 2004

The Editor will add text about the good practice of using server-side redirects to connect two resources when people start using "the wrong URI".

Acknowledgment cycle

Not started

Action history

laskey1: Editorial comments on WebArch [link to this issue]

The first two comments from the reviewer are editorial.

Transition history

raised on 1 Mar 2004 by Ken Laskey

Action history

laskey2: What determines URI uniqueness? [link to this issue]

When determining the uniqueness of a URI, is the fragment identifier 
considered part of the identifying URI?  If there is an argument list, does 
the ? and what follows constitute part of the unique URI?

Clarification concerning

2.1. URI Comparisons

Transition history

raised on 1 Mar 2004 by Ken Laskey

Action history

gilman1: 'legal requirement' as justification for 'particular presentation' misses 'leading Web to highest' mark [link to this issue]

Excerpt: "The reader is left with the impression that 'obviously,
the legal requirement justifies the actual practice.  It constitutes
an overriding concern.' This is not necessarily the case.  Please don't reinforce misconceptions.  Particular if they have consequences that reduce the universality of access to web mediated transactions."

Error concerning

4.3. Separation of Content, Presentation, and Interaction

Discussion history

14 May 2004

Transition history

raised on 2 Mar 2004 by Al Gilman

agreed on 14 May 2004

The TAG believes that the 10 May 2004 draft addresses the reviewer's comment.

Acknowledgment cycle

Not started

Action history

gilman2: orthogonality is not the answer [link to this issue]

The reviewer explained why "orthogonality" was the wrong term to 
use. See email for details.

Error concerning

1.2.1. Orthogonal Specifications

Transition history

raised on 4 Mar 2004 by Al Gilman

declined on 14 May 2004

The TAG believes that "orthogonal", not "independent" is the proper term. E.g., the HTTP specification depends on the URI specification, but they are orthogonal. The TAG also decided to remove the term "loosely coupled" and to change "independent" to "may evolve independently."

Acknowledgment cycle

announced by group on 27 May 2004

Action history

lesch1: Editorial comments [link to this issue]

The reviewer suggested a number of editorial corrections

Transition history

raised on 29 Feb 2004 by Susan Lesch

Action history

schema1: [1.2.3] "Silent recovery from error is harmful." [link to this issue]

The validity of this principle depends very much on what level one is talking about. Is silent recovery from packet collisions harmful? With an ECC memory: should every correctable memory problem be reported? Must an application that normalizes input data so that out-of-range values are normalized to the valid extreme of the range report every bad data item? To whom? (Suppose the data stream represents instrument measurements streamed to a Web display.) We suggest that the rule be:

Silent recovery from errors may hinder problem diagnosis. Furthermore, silent recovery of errors resulting from erroneous input may inappropriately promote use of non-compliant data formats."

We also note that there is a tension between this principle and the notion of "must-ignore". For many applications, "what you don't understand" is equivalent to "an error". So one principle says you should ignore (presumably silently) this data, and the other says you should not.

I agree with this principle in cases where the way in which the agent
recovers affects the resulting service provided to the user. There are
error cases where this is not the case - for example, a 401 in http
where the problem was a stale nonce, or an error indicating that a
message was lost and should be retransmitted. In such cases, silent
recovery probably makes sense.

Error concerning

1.2.3. Error Handling

Transition history

raised on 4 Mar 2004 by Mary Holstege (holstege@mathling.com), on behalf of XML Schema Working Group

raised again on 21 Apr 2004 by Jonathan Rosenberg, on behalf of Internet Architecture Board

Subsumed by issue(s) on 14 May 2004

Henceforth, refer to issue dhm2.

Action history

schema2: [Section 2] Unwise confluence of identification and retrievability [link to this issue]

[Section 2] assumes that identification and retrievability are the same thing.
Given the extensive use, starting with namespaces, but continuing with the
identification of XSLT and XQuery functions, and so on, of using URIs to
identify non-retrievble and abstract entities, this conflation is problematic
at best.

Error concerning

2. Identification

Transition history

raised on 4 Mar 2004 by Mary Holstege (holstege@mathling.com), on behalf of XML Schema Working Group

agreed on 9 Aug 2004

Decided at Ottawa f2f. (No action.) The new text about information resources is believed to address this issue.

Acknowledgment cycle

Not started

schema3: [Section 2.3] Clarity required on nature of "resource" [link to this issue]

The architecture document needs to do a better job of explaining what a
resource is in this context.  (See email for more info)

Error concerning

2.3. URI Ambiguity

Transition history

raised on 4 Mar 2004 by Mary Holstege (holstege@mathling.com), on behalf of XML Schema Working Group

agreed on 9 Aug 2004

Decided at Ottawa f2f. Added 2.5.2 Representation reuse.

Acknowledgment cycle

Not started

schema4: [3.3 Good practice: Fragment Identifier Consistency] [link to this issue]

"Good practice: Fragment identifier consistency:
   A resource owner who creates a URI with a fragment identifier and who uses 
   content negotiation to serve multiple representations of the identified
   resource SHOULD NOT serve representations with inconsistent fragment
   identifier semantics.

If the term "consistent" is here used in a technical sense, please explain what it means and how inconsistencies are to be detected. If it is used in a non-technical sense, please explain what it means.

We note that if fragment identifiers must be usable in more than one MIME type, the result will be that the only fragment identifiers effectively allowed will be bare names (or other fragment identifier syntaxes incapable of knowing about or exploiting any of the structure of the data); it seems undesirable to impoverish the URI identifier space in this way.

In general, content negotiation (like server-side browser sniffing) does not seem to us to be an obviously and universally good thing: it leads to unpredictable context-dependent results in ways that are actively hostile to some machine-driven applications, and it interacts in this pernicious way with fragment identifiers. On the other hand, if content negotiation is indeed important to make things work, perhaps some advice on whether newly invented schemes should support the equivalent of content negotiation is in order.

This is not a viable best practice recommendation, except as a bandaid, as it tightly couples URIs to representations, and constrains representation evolvability in untenable ways. This appears to highlight a weakness in the Web architecture that should be explicitly addressed.

Clarification concerning

3.3. Internet Media Type

Discussion history

3 May 2004, 13 May 2004

Transition history

raised on 4 Mar 2004 by Mary Holstege (holstege@mathling.com), on behalf of XML Schema Working Group

Subsumed by issue(s) on 13 May 2004

See msm13.

Action history

schema5: [3.3.1] Inconsistency with RFC2396bis about frag id meaning? [link to this issue]

[3.3.1] says: 
   "Per [URI], in order to know the authoritative interpretation 
   of a fragment identifier, one must dereference the URI containing the 
   fragment identifier. The Internet Media Type of the retrieved 
   representation specifies the authoritative interpretation of the fragment 
   identifier. Thus, in the case of Dirk and Nadia, the authoritative 
   interpretation depends on the SVG specification, not the XHTML 
   specification (i.e., the context where the URI appears)."

But this seems to contradict the referenced URI specification, which says:

"The semantics of a fragment identifier are defined by the set of 
   representations that might result from a retrieval action on the primary 
   resource. The fragment's format and resolution is therefore dependent on 
   the media type [RFC2046] of the retrieved representation, even though such 
   a retrieval is only performed if the URI is dereferenced." 

The latter says clearly you need not dereference. On the contrary, you must know the range of representations that you might get _if_ you tried to dereference.

Error concerning

3.3.1. Media Types and Fragment Identifier Semantics

Transition history

raised on 4 Mar 2004 by Mary Holstege (holstege@mathling.com), on behalf of XML Schema Working Group

agreed on 9 Aug 2004

Decided just prior to the Ottawa f2f. Incorporating CL’s edits of 3.3.1 has fixed this issue (by making the webarch document the same as 2396bis.

Acknowledgment cycle

Not started

schema6: [3.3.1] Do fragment identifiers work only with media-typed representations? [link to this issue]

[3.3.1] says

   "Given a URI "U#F", and a representation retrieved by dereferencing 
   URI "U", the (secondary) resource identified by "U#F" is determined by 
   interpreting "F" according to the specification associated with the 
   Internet Media Type of the representation." 

What if the scheme is not HTTP and media types are not used (e.g. because the URI uses the file: scheme or for some other reason)? Do fragment identifiers work only with media-typed representations? We hope not.

Clarification concerning

3.3.1. Media Types and Fragment Identifier Semantics

Transition history

raised on 4 Mar 2004 by Mary Holstege (holstege@mathling.com), on behalf of XML Schema Working Group

schema7: [3.4.1] What is scope of metadata? [link to this issue]

[3.4.1] Says that user agents must not silently ignore server metadata.
Metadata covers a lot of ground: what is its scope? May a user agent ignore a
server-specified DTD or Schema and choose to apply a local variant
(e.g. because the user so specifies in a local configuration file or a
launch-time option)? Why not?

Clarification concerning

3.4.1. Inconsistencies between Metadata and Representation Data

Transition history

raised on 4 Mar 2004 by Mary Holstege (holstege@mathling.com), on behalf of XML Schema Working Group

schema8: [3.4.1] Authority and trust [link to this issue]

If the sender is not a trusted authority, it would be foolish for the recipient to rely on the principle of sender-makes-right. A well written production server runs an unacceptable risk if it accepts at face value everything an untrusted client tells it. Must it inform the client each time it follows its own instructions by ignoring client information?

Error concerning

3.4.1. Inconsistencies between Metadata and Representation Data

Transition history

raised on 4 Mar 2004 by Mary Holstege (holstege@mathling.com), on behalf of XML Schema Working Group

Subsumed by issue(s) on 19 Jul 2004

Overtaken by events.

schema9: [3.4.1] Are peer-to-peer interactions covered? [link to this issue]

(We also note in passing that focusing on the interactions between "user-agents" and "servers" is fundamentally limiting in the sense mentioning in our opening comment. Are not peer-to-peer interactions covered by this architecture?)

Error concerning

3.4.1. Inconsistencies between Metadata and Representation Data

Transition history

raised on 4 Mar 2004 by Mary Holstege (holstege@mathling.com), on behalf of XML Schema Working Group

Subsumed by issue(s) on 19 Jul 2004

Overtaken by events.

schema10: [3.5] Breadth of "safe" interactions [link to this issue]

[3.5] says that an interaction is safe if the agent does not incur any
obligation beyond the interaction.  This seems too broad; the TAG has been
advised of other scenarios.  For example, if each access to a resource needs to
be authenticated at the application (not https) level, but no ongoing
obligation is established, this rule suggests that the retrieval is safe.  Is
that really true?  We wouldn't want the access cached, except perhaps by an
application-specific cache that knew our authorization rules.  Consider also
the case where the provider of the resource needs to log the access.  The issue
is an important one, and the summary given here comes close to being an
oversimplification.

Error concerning

3.5. Safe Interactions

Transition history

raised on 4 Mar 2004 by Mary Holstege (holstege@mathling.com), on behalf of XML Schema Working Group

schema11: [3.5.1] Best practice that content-location SHOULD be used? [link to this issue]

[3.5.1] Says:

   "There are mechanisms in HTTP, not widely deployed, to remedy this
   situation. HTTP servers can assign a URI to the results of a POST  
   transaction using the "Content-Location" header (described in section 
   14.14 of [RFC2616]), and allow authorized parties to retrieve a record of 
   the transaction thereafter via this URI (the value of URI persistence is 
   apparent in this case). User agents can provide an interface for managing 
   transactions where the user agent has incurred an obligation on behalf of 
   the user."

Yes, but is this saying specifically that content-location SHOULD be used? If so, so. If not, then make clearer what's intended.

Clarification concerning

3.5.1. Unsafe Interactions and Accountability

Transition history

raised on 4 Mar 2004 by Mary Holstege (holstege@mathling.com), on behalf of XML Schema Working Group

schema12: [3.6.1] [3.6.1] Good practice: Available representation. Too preferential to dereferencable URIs [link to this issue]

[3.6.1] 
   Good practice: Available representation

   Publishers of a URI SHOULD provide representations of the identified
   resource.

We are concerned that this appears to privilege dereferenceable URIs over other sectors of URI space; in particular to denigrate all uses of URIs as pure (non-dereferenceable) identifiers, such as namespaces, QT functions, SOAP extensions, SAX properties, etc. etc. There are often pragmatic reasons for declining to make URIs dereferencable (unwelcome load on servers, for example, or identifiers that are intended purely for software systems and that humans will never see or need to dereference to obtain useful information). It seems to us that at least a coherent story should be told about how this pure-identification use fits into the overall Web architecture.

Error concerning

3.6.1. Representation availability

Transition history

raised on 4 Mar 2004 by Mary Holstege (holstege@mathling.com), on behalf of XML Schema Working Group

agreed on 9 Aug 2004

Decided at the Ottawa f2f. Added good practice about unnecessary network access.

Acknowledgment cycle

Not started

schema13: [4.2] Overly simplifies a complex problem [link to this issue]

[4.2] In general, the section on versioning unduly and in too many ways oversimplifies a complex, subtle, and as yet poorly understood problem. For example, 4.2.3 says:

"Language designers SHOULD provide mechanisms that allow any party to 
   create extensions that do not interfere with conformance to the original 
   specification." 

This oversimplifes a very tough tradeoff. When you allow such extensions, you promote reuse of the base language for new purposes, and that seems good. You also provide for a proliferation of potentially non-interoperable versions depending on various extensions, as well as ensuring that some data will be accepted by processors when it is in fact not conforming to a later or extended definition of the language, but is simply erroneous and ought (if the processor were only omniscient) to be rejected as such with a useful diagnostic. That's bad.

Pursuing the principle enunciated here, one might conclude that maybe XML should have let anyone who wanted to define new syntactic constructs such as structured attributes? They didn't, and interoperability is helped rather than hurt by such strictness.

There is a strong tension between versioning and extensibility and silent error handling, once you get away from human mediated interactions and interactions that do not involve mission- or life-critical applications. For computer-to-computer mission-critical applications, "fallback behaviour" is semantically equivalent to "silently handling errors" and the Web architecture document is thus self-contradictory.

In addition, versioning and extensibility are not solely a property of data representations, but of protocols as well.

Error concerning

4.2. Versioning and Extensibility

Discussion history

13 May 2004

Transition history

raised on 4 Mar 2004 by Mary Holstege (holstege@mathling.com), on behalf of XML Schema Working Group

agreed on 14 May 2004

The TAG agrees with the reviewer that the text does not communicate why extensibility may not be appropriate in some cases. Furthermore, the TAG has resolved to delete the phrase "falling back to default behavior".

Acknowledgment cycle

announced by group on 27 May 2004

Action history

schema14: [4.2.3] Must * rules in instance v. documentation [link to this issue]

[4.2.3] The discussion of mustIgnore & mustUnderstand should clarify the difference between marking the distinction in the document instance, in a schema, or in prose documentation. SOAP does it with an attribute in the instance. Schema content models do it in the schema. Other systems provide rules in the specifications. These have different tradeoffs.

Clarification concerning

4.2.3. Extensibility

Discussion history

14 May 2004

Transition history

raised on 4 Mar 2004 by Mary Holstege (holstege@mathling.com), on behalf of XML Schema Working Group

Action history

schema15: [4.2.4] SOAP message cannot include JPEG [link to this issue]

[4.2.4] Says:

"In principle, a SOAP message can contain a JPEG image that 
   contains an RDF comment which refers to a vocabulary of terms for 
   describing the image." 

This is untrue: SOAP is XML, JPEG is not. MTOM may do something to extend SOAP to make this true, but as it stands the statement is false. Perhaps "... can contain an SVG image that contains ..." is what you meant to write.

Error concerning

4.2.4. Composition of Data Formats

Discussion history

14 May 2004

Transition history

raised on 4 Mar 2004 by Mary Holstege (holstege@mathling.com), on behalf of XML Schema Working Group

declined on 14 May 2004

The TAG believes the 10 May 2004 draft addresses the reviewer's concerns.

Acknowledgment cycle

announced by group on 10 May 2004

agreement by reviewer on 11 May 2004

Satisfied with editorial change in 10 May 2004 draft.

Action history

schema16: [4.5.1] Section on when to use XML formats underdeveloped [link to this issue]

[4.5.1] is on when to use XML-based formats. The analysis here seems underdeveloped and may perhaps best be left out. If it is kept, then additional reasons for using XML documents include:

• Desire for data easily parsed by both humans and machines
• Desire for vocabularies that can be invented in a distributed manner and combined flexibly in instance documents
• Desire for a text-based format
• Availability of a wide range of tools (not just choosing tools to be used in the future: having flexibility in choosing the initial set of tools for processing is equally important)

Editorial concerning

4.5.1. When to Use an XML-Based Format

Transition history

raised on 4 Mar 2004 by Mary Holstege (holstege@mathling.com), on behalf of XML Schema Working Group

agreed on 8 Aug 2004

Classified as editorial, addressed by the editor.

Acknowledgment cycle

Not started

schema17: [4.5.3] Statement about XMLNS and unique names false [link to this issue]

[4.5.3] States:

"Namespaces in XML" [XMLNS] provides a mechanism for establishing a globally
   unique name that can be understood in any context.

This is a false statement and should not be continued to be repeated.

Error concerning

4.5.3. XML Namespaces

Discussion history

22 Mar 2004, 14 May 2004

Transition history

raised on 4 Mar 2004 by Mary Holstege (holstege@mathling.com), on behalf of XML Schema Working Group

agreed on 14 May 2004

• Delete "that can be understood in any context" (Already done in 10 May 2004 draft.)
• Modify remaining sentence to say: "Namespaces in xml use URIs in order to obtain the properties of a global namespace."
• Include a reference to 2.2 URI ownership.

Acknowledgment cycle

announced by group on 27 May 2004

Action history

schema18: [4.5.3] Clarification on "type" in XML Schema [link to this issue]

[4.5.3] Says:

"The type attribute from W3C XML Schema is an example of a global 
   attribute."  

This should indicate type in the Schema Instance namespace, preferably with a suitable link to our spec. Perhaps

"The type attribute from W3C XML Schema namespace is an example of a global
   attribute."

There are also type attributes in the schema document vocabulary, e.g. on <xsd:element>, and those are not global. Furthermore, we see above in 4.5.6 that a prefix is used to indicate xs:ID as a type. So, why not use xsi:type for this one:

"The xsi:type attribute, provided by W3C XML Schema for use in XML 
   instance documents, is an example of a global attribute."

Clarification concerning

4.5.3. XML Namespaces

Discussion history

14 May 2004

Transition history

raised on 4 Mar 2004 by Mary Holstege (holstege@mathling.com), on behalf of XML Schema Working Group

agreed on 14 May 2004

Include a clearer reference to the XML Schema specification.

Acknowledgment cycle

announced by group on 10 May 2004

agreement by reviewer on 11 May 2004

Satisfied with editorial change in 10 May 2004 draft.

Action history

schema19: [4.5.3] Element type/instance confusion [link to this issue]

[4.5.3] Says:

"Attributes are always scoped by the element on which they appear. 
    An attribute that is "global," that is, one that might meaningfully 
    appear on different elements, including elements in other namespaces,
    should be explicitly placed in a namespace. Local attributes, ones
    associated with only a particular element, need not be included in a 
    namespace since their meaning will always be clear from the context 
    provided by that element."

This appears to mix the notion of element instance and what DTD-oriented minds would call 'element type'. Perhaps this should read

An attribute that is "global," that is, one that might meaningfully appear
    on elements of any type, including elements in other namespaces, should be
    explicitly placed in a namespace. Local attributes, ones associated with
    only a particular element type, need not be included in a namespace since
    their meaning will always be clear from the context provided by that
    element."

Clarification concerning

4.5.3. XML Namespaces

Discussion history

14 May 2004

Transition history

raised on 4 Mar 2004 by Mary Holstege (holstege@mathling.com), on behalf of XML Schema Working Group

agreed on 14 May 2004

The TAG agreed with the reviewer.

Acknowledgment cycle

announced by group on 10 May 2004

agreement by reviewer on 11 May 2004

Satisfied with change in 10 May 2004 draft.

Action history

schema20: [4.5.6] Flavors of ID not discussed [link to this issue]

[4.5.6] Fails to careful highlight the particular flavours of "ID" in play, and that they are NOT the same thing. For example, consider the following three statements:

• "Does the section element have the ID "foo"?" (This needs to be something like "Does the section element have what the XML Recommendation refers to as the ID "foo"? ")
• "Processing the document with a W3C XML Schema might reveal an element declaration that identifies the name attribute as an xs:ID." (This one is probably OK.)
• "In practice, processing the document with another schema language, such as RELAX NG [RELAXNG], might reveal the attributes of type ID." (What is a "type ID" here? If it's RELAX using the schema data types, then isn't it xs:ID in this case?)

In practice, applications may have independent means of specifying IDness as provided for and specified in XPointer. XPointer carefully discusses these options.

Error concerning

4.5.6. XML ID Semantics

Discussion history

14 May 2004

Transition history

raised on 4 Mar 2004 by Mary Holstege (holstege@mathling.com), on behalf of XML Schema Working Group

agreed on 14 May 2004

The TAG believes that the 10 May 2004 draft addresses the reviewer's concern, with the following changes:

• change fourth bullet in 10 May 2004 draft to read "In practice, applications may have independent means of locating identifiers inside a document such as provided for and specified in the XPointer specification."
• Include a reference to section 3.2.

Acknowledgment cycle

announced by group on 27 May 2004

Action history

schema21: General editorial comments [link to this issue]

The end of the reviewer's mail suggests some editorial changes.

Transition history

raised on 4 Mar 2004 by Mary Holstege (holstege@mathling.com), on behalf of XML Schema Working Group

Action history

lafon1: Implications of HTTP URI implying GET as default method [link to this issue]

There is a problem with http URI implying GET as a default method and not
allowing any other method for retrieval. (See remainder of email for details).

Transition history

raised on 5 Mar 2004 by Yves Lafon (ylafon@w3.org)

msm1: editorial comments on Web Architecture document [link to this issue]

The reviewer made a number of editorial comments.

Transition history

raised on 4 Mar 2004 by C. M. Sperberg-McQueen (cmsmcq@acm.org)

msm2: WD-webarch-20031209, 1.1.3: Self-descriptive markup considered improbable [link to this issue]

The sample principle "self-descriptive markup" makes me nervous:
surely the TAG does not believe that XML (or any other system) is a
self-describing format in the sense that anyone looking at any
instance of the format will understand what is going on without having
to have recourse to any documentation?  Neither XML nor any other
format or notation matches this description.  Some formats are or can
be self-describing in that the notation can be used to describe the
notation: one can write a grammar in BNF for BNF itself, and one can
write a schema in XML to define the XML vocabulary for writing
schemas.  But such recursion is possible, surely, primarily for
notations which are intended to be used for defining notations.

Error concerning

1.1.3 Principles, Constraints, and Good Practice

Discussion history

12 May 2004

Transition history

raised on 4 Mar 2004 by C. M. Sperberg-McQueen (cmsmcq@acm.org)

declined on 12 May 2004

The TAG resolved to keep the drop shadow for aesthetic reasons.

Acknowledgment cycle

Not started

Action history

msm3: WD-webarch-20031209, 1.2.1 para 1: Assigning identifiers without knowing about representations [link to this issue]

The first paragraph of this section is incomprehensible to me; I hope it can be rewritten.

What does it mean to define an identifier without knowing what representations are available? Representations for what? For the identifier? For the thing identified? For something else entirely? In general, I would have thought that before assigning identifiers to things it would normally be useful to know what one was identifying. In programming languages, what one identifies with identifiers are typically representations of things (representations of integers, representations of character strings, etc.); in that context, it seems nonsensical to say without qualification (as is done here) that identifiers can be assigned without any knowledge about available representations; it is only a knowledge of the available representations and their characteristics that allows one to decide intelligently what different things need to be distinguished and thus what different things will need to be identified.

Error concerning

1.2.1. Orthogonal Specifications

Transition history

raised on 4 Mar 2004 by C. M. Sperberg-McQueen (cmsmcq@acm.org)

Subsumed by issue(s) on 19 Jul 2004

Overtaken by events.

Action history

msm4: WD-webarch-20031209, 1.2.1, final bulleted list, final item.: Authoritative metadata and the principle of decentralization [link to this issue]

It's clear that the world would be a better place if specifications were more consistently implemented and their nuances more consistently observed. It's not quite clear to me that the world will be a better place if we assign all authority for document metadata to the server and remove all possibility of overriding it in the document itself. The principle enunciated or illustrated here works well when the systems administrator responsible for the server knows the character encoding, content-type, etc., of each resource served, cares about serving correct metadata, and knows how to configure the server to achieve that result. It works less well when any of those conditions ceases to apply.

It is not unusual (in my experience, at least) for the author or provider of a document to know more about it than the maintainer of the Web server; if the in-line metadata and the metadata provided by the server are in conflict, it is not always my experience that the server is right and the author wrong, and it troubles me to see the web architecture document effectively disenfranchising the latter in favor of the former.

Section 3.4.1, Principle: Authoritative server metadata, says "User agents MUST NOT silently ignore authoritative server metadata" and discusses the responsibility of server managers in the provision of metadata.

This principle appears to mean that the only first-class citizens of the Web are server managers. Any content provider in the position of controlling the content, but not the server configuration, is at the mercy of the server manager; this situation is unproblematic when the server manager takes seriously the responsibilities assigned here; it seems likely to lead to problems in organizations where a typical exchange between content provider and webmaster runs like this:

  Content Provider: This document needs to be served in UTF-8, not
  ISO Latin-1.

  Webmaster: I'm busy, I don't have time for this kind of thing,
  so get lost.

  Content Provider: Also, the expiration time should be thirty days,
  not two hours.

 Webmaster: Close the door on your way out, OK?

It seems to me that local authority on metadata would be an approach more consistent with the principle of decentralization which governs Web architecture in other respects.

Error concerning

1.2.1. Orthogonal Specifications

Transition history

raised on 4 Mar 2004 by C. M. Sperberg-McQueen (cmsmcq@acm.org)

agreed on 9 Aug 2004

Decided at the Ottawa f2f. Added good practice about metadata association.

Acknowledgment cycle

Not started

msm5: WD-webarch-20031209, 1.2.2 para 5: Extensibility is a not a property of languages in isolation [link to this issue]

1.2.2 para 5 ("Ideally, many ..."). Sentence 2 ("Languages that exhibit this property are said to be 'extensible'") seems to say that if an instance of a larger language can be processed as though it were an instance of a smaller language, then the larger language is said to be "extensible". I think the term is probably better taken as referring to the smaller language; I think the paragraph should probably be rewritten from scratch, since with the current structure it will be difficult to provide a clear antecedent of the phrase "this property".

In any case, the current formulation invites the reply that OF COURSE some instances of a superset language may be processed as if they were members of a subset language: in any plausible case, a large number of members of the superset language ARE members of the subset language; that is what it means for one language to be a superset of another. I think the instances you wish to refer to particularly are those members of the superset language which are NOT instances of the subset language, but which can nonetheless successfully be processed by a suitable processor. The analysis here is weakened by its failure to acknowledge explicitly that the property in question is not a property of the language by itself but a property of the particular kind of processing involved, and the coding of the processor. (Here as elsewhere the document appears to fall into the trap of speaking as if only one kind of processing were liable to be applied to any particular document, or any particular language; this is not the case for any language intended to promote the reuse and repurposing of data, and that fact is of material importance in any discussion of extensibility.)

Error concerning

1.2.2. Extensibility

Transition history

raised on 4 Mar 2004 by C. M. Sperberg-McQueen (cmsmcq@acm.org)

msm6: WD-webarch-20031209, 1.2.2 para 5: Ignoring the unknown as a default action [link to this issue]

1.2.2 para 5 ("Ideally, many ..."). I think the end of the paragraph would be more persuasive if "ignore" and "treat as error" were not the only examples given of default processing rules. The "ignore" approach is (as formulated here and elsewhere) an oversimplification. It is both underspecified and excessively specific. Underspecified, because most proponents do not distinguish between ignoring the unknown element and ignoring the tags which mark the beginning and ending of the unknown element, and some participants in the discussion fail to understand the difference, as is illustrated by the following paragraph of this document. Excessively specific, because ignoring is not the only plausible default processing rule, and in many contexts it's easy to think of a better. A pretty-printer should use its default line-break and indentation rules; a search system should use its default indexing rules; an editor should use its default display; a transformation system should perform the identity transform, or suppress the element (is this the same as 'ignoring' it? I don't think so), or perform another default action (such as the default action specified by XSLT). These do not all seem to me to be the same as "ignoring" either the element or the tags.

Error concerning

1.2.2. Extensibility

Transition history

raised on 4 Mar 2004 by C. M. Sperberg-McQueen (cmsmcq@acm.org)

msm7: WD-webarch-20031209, 1.2.2 para 6: Ignoring elements and ignoring tags [link to this issue]

1.2.2 para 6 ("For example, from ...") says "from early on in the Web, HTML agents followed the convention of ignoring unknown elements." I think you mean to say "ignoring unknown tags" instead; I think many of your readers will, like me, understand "tags" as marking the beginnings and endings of "elements", and many of them may, like me, be confused at first by this sentence, which seems to mischaracterize browser behavior. At least in my experience, browsers ignore tags, such as the start- and end-tags of 'blink' elements, but do not ignore elements, which is why the content of 'script' elements must be wrapped in comments in order to avoid problems with earlier browsers, which ignore the 'script' tags, but not the 'script' element. (It is possible that this sentence is intended to refer to some different browser behavior, such as ignoring the absence of explicit end-tags, or the typical decision by browsers to ignore violations of SGML's element nesting rules; in this case, reformulating the sentence is even more important.)

Editorial concerning

1.2.2. Extensibility

Transition history

raised on 4 Mar 2004 by C. M. Sperberg-McQueen (cmsmcq@acm.org)

agreed on 9 Aug 2004

Classified as editorial; fixed by the editor.

Acknowledgment cycle

Not started

msm8: WD-webarch-20031209, Section 2, introductory paragraphs: The term 'resource' needs to be defined [link to this issue]

Section 2, introductory paragraphs. In the introduction to this section, the failure of the document to make any serious attempt to define the term 'resource' begins to bite you -- and more to the point, begins to cause problems for the reader. I recognize that it's difficult to define 'resource' well, but I believe it essential that you try. If definition proves absolutely impossible, you can of course take it as an undefined primitive notion, but to make that approach useful I think you would need to specify explicitly the relations which are postulated as holding between resources and other primitive notions.

In the current draft, you are making things too easy on yourselves; the document suffers.

Some questions one might hope to have some light shed on by either a definition or by a non-defining description of resource as a primitive notion:

• How many resources are there, or how many could there be?
• Can resources be created or come into existence at a particular point in time?
• Can resources cease to exist?
• Can a set of resources be a resource?
• Can a part of a resource be a resource?
• Do all users of the Web operate with the same set of resources, or is it possible for one user to identify three resources where another identifies only two, without either of them being in error?
• Who determines the identity of a resource?
• If the question arises whether two URIs designate the same resource, can there be an authoritative answer to the question, or is it a judgement question like the question 'Is "love" an adequate English rendering for the Greek word "agape"?', on which every thoughtful observer may form an independent opinion?
• It is clear that various parts of the architecture document assume that some resources have owners. Do any resources have multiple owners? Do any resources lack owners?

Error concerning

2. Identification

Transition history

raised on 4 Mar 2004 by C. M. Sperberg-McQueen (cmsmcq@acm.org)

msm9: WD-webarch-20031209, Section 2 para 3: The vastness of URI space [link to this issue]

Section 2 para 3 says

    When a representation uses a URI (instead of a local identifier)
    as an identifier, then it gains great power from the vastness of
    the choice of resources to which it can refer. 

This suggests that URIs have the advantage, compared to local identifiers, of being more numerous. But if we assume that both URIs and local identifiers are finite-length strings without any length restriction we need worry about, then both sets are enumerably infinite and there is a one-to-one mapping between them, so that they have exactly the same cardinality and neither is any more vast than the other.

I suspect that what is meant here is that URIs have the advantage of being dereferenceable; this is true of some URIs, but not, I think, of all.

Error concerning

2. Identification

Transition history

raised on 4 Mar 2004 by C. M. Sperberg-McQueen (cmsmcq@acm.org)

Subsumed by issue(s) on 19 Jul 2004

Overtaken by events.

Action history

msm10: WD-webarch-20031209, Section 2: Assigning URIs to resources others will expect to refer to [link to this issue]

Section 2, Principle: URI assignment says: "A resource owner SHOULD assign a URI to each resource that others will expect to refer to."

In order to comply with this principle, it seems to be necessary for resource owners to know what resources they own, or (equivalently) to know, of each thing they own, whether it is a resource or not. It doesn't seem plausible to expect compliance with this principle if "resource" is not defined more informatively than it is defined in this document.

It may also be noted in passing that this principle also requires that resource owners predict what other actors will expect; it would be nice if the principle could be reformulated without requiring owners to perform such predictions.

Note also that if resources can be any "items of interest" (as stated by section 1), it may be impossible for a resource owner to provide URIs for every resource which may be an item of interest. If there is an owner of the real numbers, for example, that owner cannot comply with the principle enunciated here. If anyone owns an infinite set of items of interest, and if sets of such items are thought to be themselves potential items of interest, then that owner cannot, in principle, provide URIs for all items of interest: the power set of an enumerably infinite set is not enumerable, and neither URIs nor any other finite names can be provided for all the members of a non-enumerable set.

I wonder if some slightly less demanding principle ought to be enunciated.

Error concerning

2. Identification

Transition history

raised on 4 Mar 2004 by C. M. Sperberg-McQueen (cmsmcq@acm.org)

Subsumed by issue(s) on 19 Jul 2004

Overtaken by events.

Action history

msm11: WD-webarch-20031209, Section 2.2, bulleted list, first item: Delegation of authority in hierarchical URIs [link to this issue]

Section 2.2, bulleted list, first item. It would be useful, I think, if this were expounded at greater length. It is not necessarily clear to all readers (it is, for example, not entirely clear to me) how the hierarchical delegation here postulated follows from the wording of the specifications defining the HTTP and mailto schemes.

Error concerning

2.2 URI Ownership

Transition history

raised on 4 Mar 2004 by C. M. Sperberg-McQueen (cmsmcq@acm.org)

Subsumed by issue(s) on 19 Jul 2004

Overtaken by events.

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

This reader wonders at this point whether there are any constraints on the interpretation which the definer of a media type can place on fragment identifiers for the media type. Can one, consistent with Web architecture (if not necessarily with good design) define a media type (let us say application/sortes) where the meaning of a fragment identifier is identified by taking a checksum of the octet string returned, the conventional numerological value of the string used as the fragment identifier, multiplying the one by the other, and using the product to look up a passage in a copy of Vergil, with the stipulation that the meaning of the fragment identifier is "the meaning of the passage found by this method"?

Error concerning

3.3.1. Media Types and Fragment Identifier Semantics

Transition history

raised on 4 Mar 2004 by C. M. Sperberg-McQueen (cmsmcq@acm.org)

msm13: WD-webarch-20031209, Section 3.3.2, para 3: Consistency of fragment identifiers [link to this issue]

Section 3.3.2, para 3 ("On the other hand ...") says "it is considered an error if the semantics of the fragment identifiers used in two representations of a secondary resource are inconsistent." What does "inconsistent" mean here? How do the responsible parties determine whether a given plan of using fragment identifiers is or is not compliant with this rule?

Suppose that an internet media type (application/my-magic-mediatype) is defined with the basic rule that it is represented by servers as an XML data stream rooted in a particular namespace (e.g. one for purchase orders), and that its fragment identifers are syntactically identical to those of the application/xml media type, but denote not individual XML elements or attributes but instead whatever real-world objects are represented by those elements or attributes (a customer, an invoice, a payment obligation, ...), if any, or else have no denotation.

Suppose further that a resource owner serves the same octet sequence as two different media types (e.g. application/xml and application/my-magic-mediatype). Is the resource owner (a) obeying the principle enunciated here, given that the denotations of the fragment identifier in the two cases stand in a predictable and plausible relation to each other? or (b) violating this principle, given that in the two cases the fragment identifier identifies objects of radically different classes (XML elements on the one hand, people and other non-XML entities on the other)?

Error concerning

3.3.2. Fragment Identifiers and Multiple Representations

Discussion history

13 May 2004

Transition history

raised on 4 Mar 2004 by C. M. Sperberg-McQueen (cmsmcq@acm.org)

agreed on 13 May 2004

The TAG resolved to make the following changes to the document:

• Include three examples about coneg as proposed by TBL.
• State clearly that it's an error for representation providers to provide representations with inconsistent frag id semantics.
• Talk about consistency as being in the eye of the representation provider (not forgetting that users also have expectations). Thus, the answer to the reviewer's last question is: the notion of consistency is in the eye of the representation provider.

Acknowledgment cycle

announced by group on 27 May 2004

Action history

msm14: WD-webarch-20031209, Section 4.2.2, Story: Allowing extra attributes does change the conformance of existing data [link to this issue]

Section 4.2.2, Story. The text says that defining a new optional "lang" attribute on a "film" element does not affect the conformance of any existing data or software. This isn't quite true: it changes some invalid data (data with the undefined attribute "lang") into valid data, and some non-conforming software (software which erroneously accepts that invalid content) into conforming software.

The text is correct if, but only if, the universe of discourse is restricted to valid data.

Error concerning

4.2.2. Versioning and XML Namespace Policy

Discussion history

14 May 2004

Transition history

raised on 4 Mar 2004 by C. M. Sperberg-McQueen (cmsmcq@acm.org)

declined on 14 May 2004

The TAG agrees with the reviewer regarding the general case, but it doesn't apply to this specific instance. The TAG does not feel changes to the document are required.

Acknowledgment cycle

announced by group on 27 May 2004

baker1: Independence between identifier and resource, or representations? [link to this issue]

- the 2nd sentence of the 2nd paragraph in section 2.5 says "For
robustness, Web architecture promotes independence between an identifier
and the identified resource.".  Should it not say "... the identified
resource and its representations."?

Clarification concerning

2.5. URI Opacity

Transition history

raised on 5 Mar 2004 by Mark Baker (distobj@acm.org)

Subsumed by issue(s) on 11 Mar 2004

The reviewer retracted the issue.

baker2: More info on non-browser Web [link to this issue]

I concur with the XML Schema WG's comment that the document is too
focused on browser-based interactions rather than on the more general
problem of automata interaction.  I understand the TAG's reluctance to
tackle the Web-vs-Web-services issue, but I think it's important for
AWWW to at least give the impression - if not outright say - that there
exists solutions to the automata integration problem within the
constraints/guidelines/principles of Web architecture.  Some other
examples in section 3 would help there.

Request concerning

3. Interaction

Transition history

raised on 5 Mar 2004 by Mark Baker (distobj@acm.org)

Subsumed by issue(s) on 19 Jul 2004

Overtaken by events.

baker3: Editorial comments [link to this issue]

The reviewer's first, fourth, and fifth points are editorial.

Transition history

raised on 5 Mar 2004 by Mark Baker (distobj@acm.org)

baker4: 4.5.2: Preference for RDF linking over XLink linking [link to this issue]

in section 4.5.2, I'm uncomfortable with the recommendation to use
XLink when using XML, except perhaps when authoring documents which are
intended for human consumption.  I believe that RDF/XML provides
superior linking capabilities for XML than does XLink, and IMO
preference should be given to it.  Alternately, listing both as options
would be adequate.

Error concerning

4.5.2. Links in XML

Transition history

raised on 5 Mar 2004 by Mark Baker (distobj@acm.org)

parsia1: LC Comments: 1.2.1, editorial [link to this issue]

The reviewer made a number of editorial comments on section
1.2.1.  See email for details.

Editorial concerning

1.2.1. Orthogonal Specifications

Transition history

raised on 5 Mar 2004 by Bijan Parsia (bparsia@isr.umd.edu)

parsia2: LC Comment 1.3.1, editorial [link to this issue]

The reviewer made a number of editorial comments on section
1.2.2.  See email for details.

Editorial concerning

1.2.2. Extensibility

Transition history

raised on 5 Mar 2004 by Bijan Parsia (bparsia@isr.umd.edu)

parsia3: LC Comment, 1.2.3: Principle: Error recovery [link to this issue]

The reviewer asked a number of questions about
the principle of error recovery. See email for details.

See issue clark5.

Clarification concerning

1.2.3. Error Handling

Transition history

raised on 5 Mar 2004 by Bijan Parsia (bparsia@isr.umd.edu)

parsia4: LC Comments, 1.2.4, editorial [link to this issue]

The reviewer made a number of editorial comments on section
1.2.4.  See email for details.

Editorial concerning

1.2.4. Protocol-based Interoperability

Transition history

raised on 5 Mar 2004 by Bijan Parsia (bparsia@isr.umd.edu)

parsia5: LC Comment, Section 2: Agreement on identifiers [link to this issue]

Parties who wish to communicate must agree upon a shared set of 
identifiers and on their meanings.

This is false. A baby communicates distress and discomfort to his or her parents without there being any identifers, or even any identification going on on the part of the baby. I might be able to communicate that this large bolder crushing my leg should be removed by the stout and helpful non-english-speaking lass beside me by making somewhat spastic gesticulations. Or, in a more structured way, I might point at the bolder, or wap the bolder, and make a little rolling motion with my hands.

A number of editorial comments followed

Error concerning

2. Identification

Transition history

raised on 5 Mar 2004 by Bijan Parsia (bparsia@isr.umd.edu)

Subsumed by issue(s) on 19 Jul 2004

Overtaken by events.

parsia6: LC Comment, Section 2: Identification mechanism of the Web [link to this issue]

The identification mechanism for the Web is the URI.

Presumably this isn't *quite* right, as there is a need for some idenification mechanisms that are not URI based in order to associate (some, at least) URIs with resources for subsequent reidentification. Also, for example, host names identify things very critical to the functioning of the web, and yet, aren't URIs. Etc.

Error concerning

2. Identification

Transition history

raised on 5 Mar 2004 by Bijan Parsia (bparsia@isr.umd.edu)

Subsumed by issue(s) on 19 Jul 2004

Overtaken by events.

parsia7: LC Comment, Section 2: On requirement to assign a URI to a resource [link to this issue]

A URI must be assigned to a resource in order for agents to be able 
to refer to the resource.

Even restricted to software agents, this is false. _x foaf:mbox <mailto:bparsia@isr.umd.edu>.

Allows an OWL Reasoner to refer to me (since foaf:mbox is an InverseFunctionalProperty). (While there was a URI involved, it wasn't assigned *to me*.) I can make or refute assertions about me in this way.

Error concerning

2. Identification

Transition history

raised on 5 Mar 2004 by Bijan Parsia (bparsia@isr.umd.edu)

Subsumed by issue(s) on 19 Jul 2004

Overtaken by events.

Action history

parsia8: LC Comment, Section 2: On resources existing before URIs [link to this issue]

Resources exist before URIs;

If URIs are strings, and string are abstract mathematical entities (i.e., a kind of data structure) independant of their physical instantiation, then, reasonably, URIs have always existed, so any particular URI has existed before some recently come into existent Resources. I'm not even sure of the point of such metaphysical statements. Or imagine I have, oh, a programming language where I have URI objects (a subclass of String). Let's say I want to use a URI to identify some other objects in my system. Does this claim require that (in pseudopython):

my_object_uri = URI('http://blahblah.com/blah') #The URI now
exists!

my_funky_object = FunkyObject() #Now the Resource in question
exists.

my_object_uri.assigned_to(my_funky_object)

is broken in some way? Why would this matter?

Clarification concerning

2. Identification

Transition history

raised on 5 Mar 2004 by Bijan Parsia (bparsia@isr.umd.edu)

parsia9: LC Comment, Section 2: On resources being able to have zero URIs [link to this issue]

a resource may be identified by zero URIs.

Ah, this is what you mean? It's not very happy either. I take it you mean that some resource might *not* be identified by *any* URI. Cool. And given my above example, it might still be possible for agents to refer to it. Naturally, it's often a good idea to give various resources a URI! For example, I don't think it's possible (or, at least, easy) to *link* to something in a machine readable way in HTML. So, give such resources URIs, please. I think it's quite possible to make the sensible point without appeal to broken metaphysics.

Actually, the rest of the paragraph seems quite good and sensible.

Error concerning

2. Identification

Transition history

raised on 5 Mar 2004 by Bijan Parsia (bparsia@isr.umd.edu)

Subsumed by issue(s) on 19 Jul 2004

Overtaken by events.

parsia10: LC Comment, Section 2: On URI assignment [link to this issue]

Principle: URI assignment.
A resource owner SHOULD assign a URI to each resource that others will 
expect to refer to.

I would recommend the TAG study FOAF because that community has made a different choice (i.e., to rely a lot on inverseFunctionalProperties).

Aside from that, I think this principle misses an important point: Formats and protocols should (often?) be designed to use URIs. This encourages URI assignment by adding value to such assignment.

Error concerning

2. Identification

Transition history

raised on 5 Mar 2004 by Bijan Parsia (bparsia@isr.umd.edu)

Subsumed by issue(s) on 19 Jul 2004

Overtaken by events.

parsia11: URI assignment v. use. Who are URI producers? [link to this issue]

I don't see how to usefully split the discussion of this section, as the first line of 2.2 refers to 2.3.

The requirement for URIs to be unambiguous demands that different 
agents do not assign the same URI to different resources.

But it's ok that the same agent does so? Sorry if that sounds snarky, but it is a genuine question. I would have thought that the primary case was the resource owner...thus far, in the document, no one else seems to have the power to *assign* the same URI to different resources. E.g., principle: URI Assignment, the first line of 2.1, Good Practice: URI aliases.

(Hmm. In 2.1, right after Good Practice: URI Aliases, we get the notion of URI Producers. Who are they? Frankly, I don't find the arbitrary shifting of terms of art in a technical document to be helpful. None of these terms are defined in the glossary, either. Perhaps this isn't a technical document? If so, I'm going to feel a bit sheepish reading it this closely. Section 1.1.1 suggests that it is meant to be a guide for technical people like me (I do all of 1-4). Hmm. Section 1.1.2 says: """This document strikes a balance between brevity and precision while including illustrative examples.""" Ok, that gives me some standard. I think the above claim doesn't strike the right balance between brevity and precision.)

There's another reading, to wit, that the *URI* can be unambiguous (say, because ambiguity of a URI is defined to be having being assigned to more than one resource, and assignment can literally only be done by the URI owner, and the URI *can* successfully only assign it to one resource (none of these are obvious!)) while various agents can *use* it ambiguously. On this reading, the requirment of URI ambiguity does *not* demand that different agents do not *use* the same URI to refer to different resources. (I don't know if you mean "assign" up there in the restricted sense I was using in the definition of ambiguity, or just to mean "refer", or something else.)

Editorial concerning

2.2. URI Ownership

Transition history

raised on 5 Mar 2004 by Bijan Parsia (bparsia@isr.umd.edu)

agreed on 8 Aug 2004

Classified as editorial, addressed by the editor. Removed the word “producers” and attempted to clarify the introduction to the URI ownership section.

Acknowledgment cycle

Not started

parsia12: Ambiguous use of URIs v. URI Ambiguity? [link to this issue]

Section 2.3 says that the ambiguous *use* of URIs is to be avoided (though, I'll point out, that the Good Practice is ambiguous between ambiguous URIs and ambiguous *use* of URIs).

Of course, certain ambiguity doesn't matter, e.g., replicating Quine, I might use a URI to refer to me, the human being, and someone else to refer to the collection of undetatched people parts. As long as all our uses *align* in (all) our interactions, we're fine, ambiguous assignment or not.

Sorry for the quick digression into philosophy of languages, but, really, at this time of night, I feel a little justified in turn around :)

Error concerning

2.3. URI Ambiguity

Transition history

raised on 5 Mar 2004 by Bijan Parsia (bparsia@isr.umd.edu)

Subsumed by issue(s) on 19 Jul 2004

Overtaken by events.

parsia13: Use of term "URI Space" [link to this issue]

Hierarchical delegation of authority. This approach, exemplified by 
the "http" and "mailto" schemes, allows the assignment of a part of URI 
space to one party, reassignment of a piece of that space to another, 
and so forth.

First use of 'URI space', which is undefined. I see 'information space', 'uniform address space', and, of course, 'namespace'. As far as I can tell, only 'namespace' has a definition (and it's not in this doc, which is fine). Perhaps this is only editorial. A URI space seems clear (a set of URIs? why not say that then?), but I did spend some time wondering if it was the same as an infromation space or address space. *Are* you using unambiguous phrases here? Are they aliases? Is there a problem with either defining terms or using only one where there's only one concept? Some principles of the web apply well to technical prose.

Clarification concerning

2.3. URI Ambiguity

Transition history

raised on 5 Mar 2004 by Bijan Parsia (bparsia@isr.umd.edu)

parsia14: Various types of ownership [link to this issue]

Whatever the techniques used, except for the checksum case, the 
agent has a unique relationship with the URI, called URI ownership.

Here is what I can find on what's an "agent", prior to this passage:

Within each of these systems, agents (people and software)

strate typical behavior of Web agents \x{2014} people or software (on 
behalf of a person, entity, or process) acting on this information 
space. Software agents include servers, proxies, spiders, browsers, and 
multimedia players.

So, an agent is a person or a program. Thus, every http uri has, supposedly, one, and only one, person or program that is its owner. However, institutional ownership seems possible, as is joint ownership.

Clarification concerning

2.2. URI Ownership

Transition history

raised on 5 Mar 2004 by Bijan Parsia (bparsia@isr.umd.edu)

parsia15: Social implications of URI ownership. [link to this issue]

The social implications of URI ownership are not discussed here. 
However, the success or failure of these different approaches depends 
on the extent to which there is consensus in the Internet community on 
abiding by the defining specifications.

First you say that the social implications of URI ownership are *not* discussed here, then go on to discuss some social implications. Don't do that.

I don't believe the second statement of that quote, at least on many interpretations, and I've objected to its use in various technical arguments, some with TAG members. If this passage is to be a stick to beat me with in technical debate in W3C working groups, then I strenuously object to it, especially without substantial explication and clarification. So, I make the strong comment that I want this line struck. I object to it.

Error concerning

2.2. URI Ownership

Transition history

raised on 5 Mar 2004 by Bijan Parsia (bparsia@isr.umd.edu)

parsia16: No conformance section? Guidance on usage then? [link to this issue]

Is anything in this document normative? I notice that there is some rejection of adding a conformance section, which is fine, but I have *NO* idea how to use this document in working groups, nor do I know how it may be used by others. I totally fail to see how this can be helpful. So, I would like some guidance about that.

Clarification concerning

1.1. About this Document

Transition history

raised on 5 Mar 2004 by Bijan Parsia (bparsia@isr.umd.edu)

parsia17: Do you mean resource or representation? [link to this issue]

It is tempting to guess the nature of a resource by inspection of a 
URI that identifies it. However, the Web is designed so that agents 
communicate resource state through representations, not identifiers. In 
general, one cannot determine the Internet Media Type of 
representations of a resource by inspecting a URI for that resource. 
For example, the ".html" at the end of "http://example.com/page.html" 
provides no guarantee that representations of the identified resource 
will be served with the Internet Media Type "text/html". The HTTP 
protocol does not constrain the Internet Media Type based on the path 
component of the URI; the server is free to return a representation in 
PNG or any other data format for that URI."

First sentence talks about inferring the *nature* of a *resource* by URI inspection (i.e., inferring that <http://ex.org/#BijanThePerson>> rdf:type Person. from the URI alone). But the third sentence through the rest of the paragraph talks about inferring the Mimetype of the *representation* of the (state of) the resource. If you mean to discourage both practices, some serious reworking is in order.

Clarification concerning

2.5. URI Opacity

Transition history

raised on 5 Mar 2004 by Bijan Parsia (bparsia@isr.umd.edu)

parsia18: Temporal URL ambiguity useful for Web robustness? [link to this issue]

Resource state may evolve over time. Requiring resource owners to 
change URIs to reflect resource state would lead to a significant 
number of broken links. For robustness, Web architecture promotes 
independence between an identifier and the identified resource.

I just wonder how this is different from:

Resources may come and go over time. Requiring resource owners to 
abandon URIs to reflect resource non-existence woudl lead to a 
significant number of broken links. For robustness, Web architecture 
promotes independence between an identifier and the identified 
resource."

Of course, you might say that abandoning URIs isn't what's required, but rather maintaining legacy state. But then you've either changed the resource (to something "representing" the nonexistence resource), or you return representations reflecting the state of a nonexistence resource. Of which there isn't any.

(Note that I'm not talking about imaginary entities, but ones who have ceased to exist.)

The logic of avoiding broken links suggests that temporal URL ambiguity might be useful for Web robustness (which might not be the same as correctness).

Clarification concerning

2.5. URI Opacity

Transition history

raised on 5 Mar 2004 by Bijan Parsia (bparsia@isr.umd.edu)

parsia19: Ok to infer properties of retrieved representations? [link to this issue]

Good practice: URI opacity.
Agents making use of URIs MUST NOT attempt to infer properties of the 
referenced resource except as licensed by relevant specifications.

This says nothing about not inferring properties of the retrieved representations.

Clarification concerning

2.5. URI Opacity

Transition history

raised on 5 Mar 2004 by Bijan Parsia (bparsia@isr.umd.edu)

parsia20: Drop definition of "on the Web" [link to this issue]

Note: The Web Architecture does not require a formal definition of 
the commonly used phrase "on the Web." Informally, a resource is "on 
the Web" when it has a URI and an agent can use the URI to retrieve a 
representation of it using network protocols (given appropriate access 
privileges, network connectivity, etc.).

Given that Web Arch doesn't require it, I would recommend not including even an informal definition. Especially as it seems wrong, e.g., such that tel:+1-816-555-1212 and any URN identified resources aren't on the web (though they are possible subjects and objects (and I guess predicates; URNs certainly) of RDF assertions). Is there a relation between being "on the Web" and being, er, part of the "information space" that is the web?

So, I think this note is strike worthy.

Proposal concerning

3. Interaction

Transition history

raised on 5 Mar 2004 by Bijan Parsia (bparsia@isr.umd.edu)

Subsumed by issue(s) on 19 Jul 2004

Overtaken by events.

Action history

parsia21: Drop sentence on successful communication [link to this issue]

Successful communication between two parties using a piece of 
information relies on shared understanding of the meaning of the 
information.

I'll spare you the critical analysis of the opening platitude of a section of a document. It's not clear to me, however, that they are, in fact, useful.

Proposal concerning

3.4. Authoritative Representation Metadata

Transition history

raised on 6 Mar 2004 by Bijan Parsia (bparsia@isr.umd.edu)

Subsumed by issue(s) on 19 Jul 2004

Overtaken by events.

parsia22: What does "in general" mean? Would the case be different "in specific"? [link to this issue]

Arbitrary numbers of independent parties can identify and 
communicate about a Web resource. To give these parties the confidence 
that they are all talking about the same thing when they refer to "the 
resource identified by the following URI ..." the design choice for the 
Web is, in general, that the owner of a resource assigns the 
authoritative interpretation of representations of the resource.

So, this is "in general", which suggests that "in specific" this might not be the case. For example, when the owner of the resource, uh, *gets it wrong*. One example is ""Inconsistencies between Metadata and Representation Data"".

So, let's generalize. What if the owner of the resource gets the *information* encoded in the message wrong? Is that authoritative? What would that mean? Suppose I retrieve a representation of my purchase order, does the resource owner have an authorative interprestion of the *meaning of the order*, interpreting my "5 very cheap things, please" as "5000 hugely expensive things, you bastard!!!"?

There is a sensible thing buried in here, I think. I think it's quite right to be judicious in ignoring narrow, well understood and somewhat verifiable represenation metadata. One example (if there were a media type for OWL-DL and OWL-Full as well as RDF) would be interpreting a retrieved ontology as OWL-DL vs. just as RDF. Different inferences are licenced, and there are times where one might want to publish the ontology for RDF interpretation only.

Of course, really, it would be best if the format provided a way to specify this.

Clarification concerning

3.4. Authoritative Representation Metadata

Transition history

raised on 6 Mar 2004 by Bijan Parsia (bparsia@isr.umd.edu)

nottingham1: Second bullet doesn't make sense. [link to this issue]

The second bullet doesn't make much sense; it seems to argue that META tags are capable of specifying new HTTP headers on the fly. While I suppose someone could make up a new header and stick it in a META tag, this really isn't the point. It also surmises that this somehow leads to the feature not being widely deployed; I believe that the reason is much more down-to-earth; performance.

Error concerning

1.2.1. Orthogonal Specifications

Transition history

raised on 5 Mar 2004 by Mark Nottingham (mnot@mnot.net)

agreed on 9 Aug 2004

Decided at the Ottawa f2f. Redrafted 5.1 'Orthogonal Specifications'.

Acknowledgment cycle

Not started

nottingham2: Include reference to IANA Registry of HTTP headers? [link to this issue]

[T]he TAG might be interested to know that an IANA registry of HTTP headers should be established soon; depending on the schedule of the AWWW, it may be possible to directly reference it in this section.

Editorial concerning

6. References

Transition history

raised on 5 Mar 2004 by Mark Nottingham (mnot@mnot.net)

klyne1: Proposed to drop para on view source or clarify role in webarch [link to this issue]

It is common for programmers working with the Web to write code that 
generates and parses these messages directly. It is less common, but not 
unusual, for end users to have direct exposure to these messages. This 
leads to the well-known "view source" effect, whereby users gain expertise 
in the workings of the systems by direct exposure to the underlying protocols.

It was not clear to me what is the intended significance of this with respect to Web Architecture. Suggest: explain the significance or drop this paragraph.

Clarification concerning

1.2.4. Protocol-based Interoperability

Transition history

raised on 5 Mar 2004 by Graham Klyne (gk@ninebynine.org)

klyne2: Change "other operations" to "refer to in another way" [link to this issue]

A URI must be assigned to a resource in order for agents to be able to 
refer to the resource. It follows that a resource should be assigned a URI 
if a third party might reasonably want to link to it, make or refute 
assertions about it, retrieve or cache a representation of it, include all 
or part of it by reference into another representation, annotate it, or 
perform other operations on it.

"or perform other operations on it" suggests a resource should be a very concrete thing. Suggest "or refer to it in some other way".

Editorial concerning

2. Identification

Transition history

raised on 5 Mar 2004 by Graham Klyne (gk@ninebynine.org)

klyne3: Proposal to improve text about "network effect" [link to this issue]

When a representation uses a URI (instead of a local identifier) as an 
identifier, then it gains great power from the vastness of the choice of 
resources to which it can refer. The phrase the "network effect" describes 
the fact that the usefulness of the technology is dependent on the size of 
the deployed Web.

The comment about "network effect" in the first para seems somewhat disjoint. What does it tell us about Web architecture? Suggest: "This vastness of choice gives rise to a "network effect", which refers to a technology's usefulness increasing more rapidly than the size of the network across which it is deployed"

Editorial concerning

2. Identification

Transition history

raised on 5 Mar 2004 by Graham Klyne (gk@ninebynine.org)

klyne4: Proposed rewrite of overlapping paras [link to this issue]

A URI must be assigned to a resource in order for agents to be able to 
refer to the resource. It follows that a resource should be assigned a URI 
if a third party might reasonably want to link to it, make or refute 
assertions about it, retrieve or cache a representation of it, include all 
or part of it by reference into another representation, annotate it, or 
perform other operations on it.

[...]

Resources exist before URIs; a resource may be identified by zero URIs. 
However, there are many benefits to assigning a URI to a resource, 
including linking, bookmarking, caching, and indexing by search engines. 
Designers should expect that it will prove useful to be able to share a URI 
across applications, even if that utility is not initially evident.

There seems to be some overlap between these paragraphs. And I found the first sentence of the second paragraph to be potentially confusing.

Suggest: a re-arrangement:

A URI must be assigned to a resource in order for agents to be able to 
refer to the resource. It follows that a resource should be assigned a URI 
if a third party might reasonably want to link to it, make or refute 
assertions about it, retrieve or cache a representation of it, include all 
or part of it by reference into another representation, annotate it, or 
refer to it in some other way.  A resource may exist independently of 
whether or not it has a URI; one or more URIs may be used to identify a 
given resource.

[...as before...]

There are many benefits to assigning a URI to a resource, as noted 
above.  Designers should expect that it will prove useful to be able to 
share a URI across applications, even if that utility is not initially evident.

Editorial concerning

2. Identification

Transition history

raised on 5 Mar 2004 by Graham Klyne (gk@ninebynine.org)

klyne5: Proposed to use "global across the Web" rather than "global" [link to this issue]

The scope of a URI is global; the resource identified by a URI does not 
depend on the context in which the URI appears (see also the section about 
URIs in other roles). Of course, what an agent does with a URI may vary. 
The TAG finding "URIs, Addressability, and the use of HTTP GET and POST" 
discusses additional benefits and considerations of URI addressability.

The term "global" here is not defined or qualified. Suggest "global across the Web".

Editorial concerning

2. Identification

Transition history

raised on 5 Mar 2004 by Graham Klyne (gk@ninebynine.org)

klyne6: Clarification about point on agents detecting equivalence relationships [link to this issue]

...For example, the parties responsible for weather.example.com should not 
use both "http://weather.example.com/Oaxaca" and 
"http://weather.example.com/oaxaca" to refer to the same resource; agents 
will not detect the equivalence relationship by following specifications. 

and

... Agents should not assume, for example, that 
"http://weather.example.com/Oaxaca" and "http://weather.example.com/oaxaca" 
identify the same resource, since none of the specifications involved 
states that the path part of an "http" URI is case-insensitive.

While correct, I felt this was potentially a little confusing. The first example did not seem well chosen to reflect the point I think is being made. Suggest:

...For example, the parties responsible for weather.example.com should not 
use both "http://weather.example.com/Oaxaca" and 
"http://weather.example.com/Mexico?city=Oaxaca" to refer to the same 
resource; agents will not detect the equivalence relationship by following 
specifications. 

Hmmm, maybe there's a third point to be made here, namely that the party responsible for some domain should avoid using different URIs with small, easily overlooked differences?

Clarification concerning

2.1. URI Comparisons

Transition history

raised on 5 Mar 2004 by Graham Klyne (gk@ninebynine.org)

klyne7: Use other schema than mailto as example [link to this issue]

Hierarchical delegation of authority. This approach, exemplified by the 
"http" and "mailto" schemes, allows the assignment of a part of URI space 
to one party, reassignment of a piece of that space to another, and so forth.

While technically correct, I don't think 'mailto' is a useful example of hierarchical delegation of naming authority within a URI structure. I'd suggest 'ftp:' or 'urn:' or 'file:' or 'ldap:'

Editorial concerning

2.2. URI Ownership

Transition history

raised on 5 Mar 2004 by Graham Klyne (gk@ninebynine.org)

agreed on 8 Aug 2004

Classified as editorial, addressed by the editor. s/mailto/urn/

Acknowledgment cycle

Not started

klyne8: Unclear point about ambiguity in natural language; is the point about machine processing? [link to this issue]

URI ambiguity should not be confused with ambiguity in natural language.

I'm not sure what this sentence is trying to say (what is meant here by "confused with"). From what follows, I think the intent is to say something like "justified by", in which case I think something like:

URIs should not be permitted the ambiguity that occurs in natural language.

[...existing text...]

This flexibility is not available to URIs, which should be defined to refer 
to a single concept.

[Later,] I ran across this from TimBL in one of the Tag IRC logs, which seems to capture the point more effectively.

Suggested text for 2.6: Whereas human communication tolerates such 
ambiguity, machine processing does not. Strictly, the above URI as 
identifies the information resource, some hypertext document. RDF 
applications which use it for describing properties of that page are in 
order; those who use its URL to directly assert properties of the whale are 
using it inconsistently.

Clarification concerning

2.3. URI Ambiguity

Transition history

raised on 5 Mar 2004 by Graham Klyne (gk@ninebynine.org)

klyne9: Add stronger language on not permitting unregistered URI schemes. [link to this issue]

The use of unregistered URI schemes is discouraged for a number of reasons:

This doesn't seem to be strong enough. Suggest:

The use of unregistered URI schemes is not a permitted part of the Web 
architecture, for a number of reasons:

Editorial concerning

2.4.1. URI Scheme Registration

Transition history

raised on 5 Mar 2004 by Graham Klyne (gk@ninebynine.org)

agreed on 8 Aug 2004

Classified as editorial, addressed by the editor. Use “SHOULD NOT”.

Acknowledgment cycle

Not started

klyne10: Add cross-ref to section on orthogonality [link to this issue]

Resource state may evolve over time. Requiring resource owners to change 
URIs to reflect resource state would lead to a significant number of broken 
links. For robustness, Web architecture promotes independence between an 
identifier and the identified resource.

I think a link to orthogonality (section 1.2.1) may be appropriate about here.

Editorial concerning

2.5. URI Opacity

Transition history

raised on 5 Mar 2004 by Graham Klyne (gk@ninebynine.org)

klyne11: Change "will result" to "will necessarily result" [link to this issue]

Although many URI schemes are named after protocols, this does not imply 
that use of such a URI will result in access to the resource via the named 
protocol. Even when an agent uses a URI to retrieve a representation, that 
access might be through gateways, proxies, caches, and name resolution 
services that are independent of the protocol associated with the scheme name.

As phrased, I find this to be at odds with the text that follows, cf. numbered items 4/5/6. Suggest replace:

use of such a URI will result

with

use of such a URI will necessarily result 

Clarification concerning

3.1. Using a URI to Access a Resource

Discussion history

26 Apr 2004

Transition history

raised on 5 Mar 2004 by Graham Klyne (gk@ninebynine.org)

agreed on 26 Apr 2004

The TAG agreed with the proposal to add "necessarily."

Acknowledgment cycle

Not started

Action history

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

On the other hand, it is considered an error if the semantics of the 
fragment identifiers used in two representations of a secondary resource 
are inconsistent.

This seems a rather odd statement to make (specifically: "it is considered an error ...", because there is no specific way to determine if the would-be erroneous condition actually arises. Suggest: drop this paragraph; the intent is clear enough from the following good practice point.

Error concerning

3.2. Messages and Representations

Discussion history

3 May 2004

Transition history

raised on 5 Mar 2004 by Graham Klyne (gk@ninebynine.org)

agreed on 3 May 2004

The TAG agrees with the reviewer's point, but has decided to keep the text and clarify it. At their 13 May 2004 ftf meeting, the TAG resolved:

• To remove "During a retrieval action" from the 10 May 2004 Editor's Draft.
• Delete from "Note..." to end of paragraph.

Acknowledgment cycle

announced by group on 27 May 2004

Subsumed by issue(s) on 19 Jul 2004

Overtaken by events.

Action history

klyne12b: Drop "by design" or replace with "by intent" [link to this issue]

For a given resource, an agent may have the choice between representation 
data in more than one data format (through HTTP content negotiation, for 
example). Since different data formats may define different fragment 
identifier semantics, it is important to note that by design, the secondary 
resource identified by a URI with a fragment identifier is expected to be 
the same across all representations. Thus, if a fragment has defined 
semantics in any one representation, the fragment is identified for all of 
them, even though a particular data format may not be able to represent it.

The term "by design" seems rather odd here. It seems to me that the (technical) design specifically does not achieve "the secondary resource identified by a URI with a fragment identifier is ... the same across all representations".

I think the clause "by design" could be dropped without loss (or, maybe, replaced with something like "by intent").

Editorial concerning

3.3.2. Fragment Identifiers and Multiple Representations

Transition history

raised on 5 Mar 2004 by Graham Klyne (gk@ninebynine.org)

klyne13: Text on communication between two parties misses mark about global names [link to this issue]

Successful communication between two parties using a piece of information 
relies on shared understanding of the meaning of the information. Arbitrary 
numbers of independent parties can identify and communicate about a Web 
resource. To give these parties the confidence that they are all talking 
about the same thing when they refer to "the resource identified by the 
following URI ..." the design choice for the Web is, in general, that the 
owner of a resource assigns the authoritative interpretation of 
representations of the resource.

I recall that TimBL and Pat Hayes had a lengthy debate about something rather like this. See Thread with some indication of consensus around this mail and this email. I am not sure that the above text really captures the subtlety of this discussion. As Pat Hayes noted:

 >Note though that other non-RDF systems may and do use URIs.  So the
 >principle can must be a general one of web architecture.

Names are global in scope.  OK, though (in the other branch of the
discussion) I don't think this is going to be feasible, myself, if
taken strictly. Still, I agree, its not a bad place to start, as long
as we understand that we will eventually have to replace it with
something more sophisticated.

Clarification concerning

3.4. Authoritative Representation Metadata

Transition history

raised on 5 Mar 2004 by Graham Klyne (gk@ninebynine.org)

klyne14: Managers of resource, not Oaxaca [link to this issue]

Since Nadia finds the Oaxaca weather site useful, she emails a review to 
her friend Dirk recommending that he check out 
'http://weather.example.com/oaxaca'. Dirk clicks on the link in the email 
he receives and is surprised to see his browser display a page about auto 
insurance. Dirk confirms the URI with Nadia, and they both conclude that 
the resource is unreliable. Although the managers of Oaxaca have chosen the 
Web as a communication medium, they have lost two customers due to 
ineffective resource management.

I think that "the managers of Oaxaca" should be "the managers of http://weather.example.com/".

Editorial concerning

3.6. Representation Management

Transition history

raised on 5 Mar 2004 by Graham Klyne (gk@ninebynine.org)

klyne15: Lack of separation between owner of a resource and authority for a part of URI space used to identify a resource? [link to this issue]

There are strong social expectations that once a URI identifies a 
particular resource, it should continue indefinitely to refer to that 
resource; this is called URI persistence. URI persistence is a matter of 
policy and commitment on the part of authorities servicing URIs. The choice 
of a particular URI scheme provides no guarantee that those URIs will be 
persistent or that they will not be persistent.

The terminology "authorities servicing URIs" seems to be not consistent with that used elsewhere; e.g. "authority responsible for a resource" at the start of section 3.6.1., and "URI producers" in section 2.1.

As I draft this, I think there's maybe a deeper omission here: a lack of separation between the owner or authority responsible for a resource, and the authority for a particular part of URI space that may be used to identify a resource. (cf. also my previous comment above.) If not clarified, I think this could be a source of continuing miscommunication.

Error concerning

3.6.2. URI Persistence

Discussion history

13 May 2004

Transition history

raised on 5 Mar 2004 by Graham Klyne (gk@ninebynine.org)

agreed on 13 May 2004

The TAG believes that the following minor changes to the document are sufficient to address the reviewer's concern.

• In 2.2, change to "(for example, to a server manager or someone who has been delegated part of the URI space on a given Web server).
• s/authorities servicing URIs/URI owners

Acknowledgment cycle

announced by group on 27 May 2004

Action history

klyne15b: Propose "rationally" instead of "predictably" [link to this issue]

Inconsistent representations served. Note the difference between a resource 
owner changing representations predictably in light of the nature of the 
resource (the changing weather of Oaxaca) and the owner changing 
representations arbitrarily.

The term "predictably" here seems an odd choice given the nature of the illustrative example (thinks ... butterflies flapping in Beijing, etc.). Suggest: rationally.

Editorial concerning

3.6.2. URI Persistence

Transition history

raised on 5 Mar 2004 by Graham Klyne (gk@ninebynine.org)

klyne16: Proposed improved example about using content negotiation [link to this issue]

Improper use of content negotiation, such as serving two images as 
equivalent through HTTP content negotiation, where one image represents a 
square and the other a circle.

This doesn't seem like a particularly helpful example, because in some contexts a circle and square may be genuinely different representations of a common underlying concept (e.g. alternative GraphViz presentations of an RDF graph). Suggest: "...such as serving two images as equivalent through HTTP content negotiation, where one image represents a weather map of Oaxaca and the other a street map of Chihuahua"

Editorial concerning

3.6.2. URI Persistence

Transition history

raised on 5 Mar 2004 by Graham Klyne (gk@ninebynine.org)

klyne17: Worth pointing out value of RDF descriptions depends on URI persistence? [link to this issue]

I made a note to myself at the end of this section: "Maye add a comment about metadata consistency and problems that may occur of a resource is not persistent" but now I not sure what it is I meant by this.

I think I may have been thinking about a case where RDF is used to describe some resource, but the resource whose representation is served at a given URI is allowed to change over time. Then, any RDF that uses said URI to describe the resource at some point in time becomes completely incorrect if the URI is assigned to a different resource. Is it worth trying to make a point that the value of RDF descriptions depends to a considerable extent on the stability/persistence of the URIs used?

Proposal concerning

3.6.2. URI Persistence

Transition history

raised on 5 Mar 2004 by Graham Klyne (gk@ninebynine.org)

agreed on 9 Aug 2004

Decided at Ottawa f2f. (No action.)

Acknowledgment cycle

Not started

klyne18: Use one of "data format", "format". And "language"? [link to this issue]

I notice that in this section, the terminology used slips from "data format" or just "format" to "language", without any explanation that they mean pretty much the same thing in this context (or, if they don't, without any explanation of the difference).

Editorial concerning

4. Data Formats

Transition history

raised on 5 Mar 2004 by Graham Klyne (gk@ninebynine.org)

klyne19: Unclear statement about mixing RDF vocabularies [link to this issue]

RDF allows well-defined mixing of vocabularies, and allows text and XML to 
be used as a data type values within a statement having clearly defined 
semantics.

I couldn't figure precisely what this was trying to say.

Clarification concerning

4.2.4. Composition of Data Formats

Discussion history

14 May 2004

Transition history

raised on 5 Mar 2004 by Graham Klyne (gk@ninebynine.org)

agreed on 14 May 2004

• Change third bullet to: "The semantics of combining RDF documents with multiple vocabularies is well-defined."
• Delete "and allows text and XML to be used as a data type values within a statement having clearly defined semantics."

Acknowledgment cycle

announced by group on 27 May 2004

Action history

klyne20: Say something about relationship between Hypertext Web and Semantic Web? [link to this issue]

Note however, that for general XML there is no semantic model that defines 
the interactions within XML documents with elements and/or attributes from 
a variety of namespaces. Each application must define how namespaces 
interact and what effect the namespace of an element has on the element's 
ancestors, siblings, and descendants.

I think that there may be an important point to be made here about the relationship of the "Semantic Web" with what I might call the "Hypertext Web" upon which it is built, that the "Semantic Web" provides a well-defined way to combine statements that draw upon an arbitrary number of different namespaces. (I regard this as one of the more important contributions of the Semantic Web.)

Maybe this is what the subject of my previous comment was trying to say?

Proposal concerning

4.2.4. Composition of Data Formats

Discussion history

14 May 2004

Transition history

raised on 5 Mar 2004 by Graham Klyne (gk@ninebynine.org)

agreed on 14 May 2004

The TAG resolved (SW abstaining):

• Create a new section 4.6 about use of media types to build new applications that make use of the information space. Explain that you create new "applications" such as the semantic web through new media type definitions. "Above we describe a global hypertext application which has been defined using specific Media types. The creation of other media types allows new applications to be build in the same space, using the same information space infrastructure. The semantic web is one such application, which is not described in detail in this version of this document. We expect future versions of the Arch doc to describe the semantic web in more detail."
• Remove sem web from discussion in 3.7
• Respond to reviewer that we expect future versions of the arch doc to go into more detail about the relationships among various systems.

Acknowledgment cycle

Not started

Subsumed by issue(s) on 19 Jul 2004

Overtaken by events.

Action history

klyne21: Add statement about scalability concerns [link to this issue]

Note that when content, presentation, and interaction are separated by 
design, agents need to recombine them. There is a recombination spectrum, 
with "client does all" at one end and "server does all" at the other. There 
are advantages to each: recombination on the server allows the server to 
send out generally smaller amounts of data that can be tailored to specific 
devices (such as mobile phones). However, such data will not be readily 
reusable by other clients and may not allow client-side agents to perform 
useful tasks unanticipated by the author. When a client does the work of 
recombination, content is likely to be more reusable by a broader audience 
and more robust. However, such data may be of greater size and may require 
more computation by the client.

I think there are also some scalability concerns that might be mentioned here; e.g. an application is, in general, more likely to operate at Internet scale if as much processing as possible is performed by user agents (often, clients) rather than centralized processing agents (often, servers).

Proposal concerning

4.3. Separation of Content, Presentation, and Interaction

Discussion history

14 May 2004

Transition history

raised on 5 Mar 2004 by Graham Klyne (gk@ninebynine.org)

agreed on 9 Aug 2004

Decided at Ottawa f2f.

Acknowledgment cycle

Not started

Action history

klyne22: Clarify what is meant by context having influence on use of hyperlinks [link to this issue]

Language designers SHOULD incorporate hypertext links into a data format if 
hypertext is the expected user interface paradigm.

I found this statement a bit puzzling: many data formats have nothing to do with a user interface; the preceding text says "What agents do with a hypertext link is not constrained by Web architecture and may depend on application context". So what is this trying to say?

Clarification concerning

4.4. Hypertext

Transition history

raised on 5 Mar 2004 by Graham Klyne (gk@ninebynine.org)

klyne23: Clarify section (see TBL text on identifier v. reference?) [link to this issue]

I found the text of this section less clear than was offered in an email from TimBL:

It is important to distinguish between the string which identifies
something and the BNF for a string in a document which
is used to specify the first string.  The first is an identifier.
The second has been called a "reference".   A reference
can use a relative form.

Clarification concerning

4.4.1. URI References

Transition history

raised on 5 Mar 2004 by Graham Klyne (gk@ninebynine.org)

klyne24: Is Web apart from Internet? [link to this issue]

...While it is directed at Internet applications with specific reference 
to protocols, the discussion is generally applicable to Web scenarios as well.

I am uneasy with this phrasing, as it seems to suggest the Web is somehow apart from the Internet. Suggest:

 While it is directed at Internet applications with specific reference 
to protocols, the discussion is also applicable to Web application formats.

Clarification concerning

4.5. XML-Based Data Formats

Transition history

raised on 5 Mar 2004 by Graham Klyne (gk@ninebynine.org)

klyne25: Add reference to RFC3117, section 5.1? [link to this issue]

Another reference with discussion relating to this topic of choosing to use XML can be found in RFC3117, section 5.1

Proposal concerning

4.5.1. When to Use an XML-Based Format

Transition history

raised on 5 Mar 2004 by Graham Klyne (gk@ninebynine.org)

agreed on 9 Aug 2004

Decided at Ottawa f2f. (No action.) The behavior suggested by RFC3117 was actually reversed when the actual spec went through standardization so we aren’t going to reference it.

Acknowledgment cycle

Not started

klyne26: Transcoding allowing by some or all intermediaries? [link to this issue]

These Internet Media Types create two problems: First, for data identified 
as "text/*", Web intermediaries are allowed to "transcode", i.e., convert 
one character encoding to another. Transcoding may make the 
self-description false or may cause the document to be not well-formed.

The statement "Web intermediaries are allowed to "transcode ..." seemed to me to be rather broadly applied here. Is there a specification that asserts this in general? If not, I think the comment should be constrained to something like "in some Web applications, intermediaries are allowed to transcode.

Clarification concerning

4.5.7. Media Types for XML

Discussion history

22 Mar 2004

Transition history

raised on 5 Mar 2004 by Graham Klyne (gk@ninebynine.org)

klyne27: Clarify para on "text/" and US-ASCII encoding. How does it relate to following GPN? [link to this issue]

Second, representations whose Internet Media Types begin with "text/" are 
required, unless the charset parameter is specified, to be considered to be 
encoded in US-ASCII. Since the syntax of XML is designed to make documents 
self-describing, it is good practice to omit the charset parameter, and 
since XML is very often not encoded in US-ASCII, the use of "text/" 
Internet Media Types effectively precludes this good practice.

I found this confusing, in that I wasn't clear what it was that was being said, and I couldn't see how it relates to the good practice point that immediately follows it.

Editorial concerning

4.5.7. Media Types for XML

Transition history

raised on 5 Mar 2004 by Graham Klyne (gk@ninebynine.org)

manola1: Use of "agent" as people+software is flaky throughout document. [link to this issue]

[[A travel scenario is used throughout this document to 
illustrate typical behavior of Web agents -- people or software (on 
behalf of a person, entity, or process) acting on this information space.]]

This sentence defines "Web agents" as including both people and software (as opposed to just software). However, the usage of terms like "agent", "user agent", etc. throughout the document isn't always consistent with including people in addition to software in the definition (and sometimes, but not always, the phrase "software agent" is used explicitly in places where only software is clearly meant). Further comments will illustrate this point in specific instances.

Editorial concerning

1. Introduction

Transition history

raised on 10 Mar 2004 by Frank Manola (fmanola@acm.org)

manola2: Clarify nature of resource in example [link to this issue]

[[This scenario illustrates the three architectural bases of the Web 
that are discussed in this document:

    1. Identification. Each resource is identified by a URI. In this 
travel scenario, the resource is about the weather in Oaxaca and the URI 
is "http://weather.example.com/oaxaca".]]

It would be more consistent with the rest of the example if "the resource is about the weather in Oaxaca" read "the resource is *a report* about the weather in Oaxaca."

Further, given the potential generality of the things URIs can identify, it would be helpful if there were some discussion somewhere about distinguishing between URIs identifying such distinct things as:

• a report about the weather in Oaxaca
• another report about the weather in Oaxaca produced by a second organization
• "the weather in Oaxaca" (which no one "owns", but which may be described in multiple reports created (and owned) by multiple independent parties)
• data on the weather in Oaxaca reported by on-line weather instrumentation which may be accessible to anyone, and which the creators of (a) and (b) combine with additional information (satellite photos, radar sweeps) to produce the reports (a) and (b).

Editorial concerning

1. Introduction

Transition history

raised on 10 Mar 2004 by Frank Manola (fmanola@acm.org)

manola3: Minor editorial comments [link to this issue]

The reviewer suggested a number of small editorial fixes; the editor will review them.

Transition history

raised on 10 Mar 2004 by Frank Manola (fmanola@acm.org)

manola4: Sentence about refs ends abruptly [link to this issue]

[[The section on Architectural 
Specifications includes references.]]

This sentence seems to end abruptly. References to what?

Editorial concerning

1.1.2. Scope of this Document

Transition history

raised on 10 Mar 2004 by Frank Manola (fmanola@acm.org)

manola5: Sentence on understanding REST model unclear [link to this issue]

[[Authors of protocol specifications in particular 
should invest time in understanding the REST model and consider the role 
to which of its principles could guide their design: statelessness, 
clear assignment of roles to parties, uniform address space, and a 
limited, uniform set of verbs.]]

This sentence has an "interesting" structure. For one thing, "the role to which of its principles could guide their design" seems to mix several more usual constructions, e.g., either "the role its principles could [or should] *play* in their designs" or "the *extent* to which each of its principles could [or should] guide their designs". For another, it seems as if the list of principles should follow "principles" rather than "design", as in something like: "Authors of protocol specifications in particular should invest time in understanding the REST model and consider the role its principles -- statelessness, clear assignment of roles to parties, uniform address space, and a limited, uniform set of verbs -- could play in their designs.

Clarification concerning

1.1.3. Principles, Constraints, and Good Practice

Transition history

raised on 10 Mar 2004 by Frank Manola (fmanola@acm.org)

manola6: User agent any kind of agent or just software? What does "on behalf of" include? [link to this issue]

[[A user agent acts on behalf of the user and therefore 
is expected to help the user understand the nature of errors, and 
possibly overcome them. User agents that correct errors without the 
consent of the user are not acting on the user's behalf.]]

Is "user agent" intended to be *any* kind of "agent" (human or software, as previously defined) acting on behalf of someone else (the "user", so far undefined), or just *software* that acts on behalf of a human?

Also, the text seems to equate "act on behalf of the user" with that action necessarily being helpful, which is not necessarily the way "act on behalf of" is always interpreted. The real point would seem to be that user agents that correct errors in this way may in some sense be acting on the user's behalf, but they aren't helping the user by doing it.

Clarification concerning

1.2.3. Error Handling

Transition history

raised on 10 Mar 2004 by Frank Manola (fmanola@acm.org)

manola7: "Agent" or "user agent" meant? [link to this issue]

Third bullet:  [[* An agent that encounters unrecognized 
content...]]

Given the context, this seems a bit ambiguous, since it might be taken to refer to "user agent", as well as more generally to "agent" (assuming these are different; are they?)

Clarification concerning

1.2.3. Error Handling

Transition history

raised on 10 Mar 2004 by Frank Manola (fmanola@acm.org)

manola8: Add "(names for things)" after "identifiers"? [link to this issue]

First para:  [[Parties who wish to communicate must agree 
upon a shared set of identifiers and on their meanings.]]

"identifiers (names for things)"?

Clarification concerning

2. Identification

Transition history

raised on 10 Mar 2004 by Frank Manola (fmanola@acm.org)

manola9: Why use "third party"? Who are other two? [link to this issue]

Second para:  [[It follows that a resource should be assigned a URI if a 
third party might reasonably want to link to it...]]

Why "a third party" (what are the first two parties)?

Editorial concerning

2. Identification

Transition history

raised on 10 Mar 2004 by Frank Manola (fmanola@acm.org)

manola10: Who are "designers"? Any diff between URI owner/producer? Relationship to resource owner? [link to this issue]

[[Designers should expect that it will prove useful to be able to share 
a URI across applications, even if that utility is not initially evident.]]

Why is the reference here to "designers"? Designers of what? This sounds like it should instead be "resource owners", as mentioned in the principle "URI assignment" just below.

However, there is also a related issue, which is that the terms "resource owner", "URI owner", and "URI producer" are all used in further discussion. I can imagine situations in which these (or at least the first two) might have distinct meanings, but they don't necessarily seem to be used that way. If they are distinct, it would help to have precise definitions. If they aren't distinct, it would help to pick one term and use it consistently (along with some further explanation of why they are the same).

In particular, "Resource owner" and "URI owner" would appear to be equivalent when discussing URIs that refer to resources with retrievable representations. However, given that URIs can be created to refer to other kinds of resources, it would seem that multiple URIs might be created to refer to the same resource, and those URIs would have different owners. For example, suppose I (the person Frank Manola) am the resource. It seems to me I can reasonably claim to be the owner of that resource (whether I have assigned myself a URI or not; recall that resources can have zero URIs). Independently, other people may create resources with retrievable representations (e.g., reports) that refer to me and, perhaps not knowing the URI I have assigned to myself (even if I *have* assigned one), can create URIs to refer to me (say, in RDF statements). It seems to me those other people can reasonably claim to be the owners of those latter URIs (e.g., they determine that those URIs denote me), even though they don't own the resource the URIs identify (me). Moreover, these other people (more effectively) can create URIs for the resources with retrievable representations (reports referring to, among other things, Frank Manola), and those resources (the reports) are distinct from the resource Frank Manola. In this case, it seems to me that those other people are the owners of both the resources (the reports) and the URIs that identify them.

Editorial concerning

2. Identification

Transition history

raised on 10 Mar 2004 by Frank Manola (fmanola@acm.org)

manola11: Proposed improvement to GPN on URI assignment [link to this issue]

[[Principle:  URI assignment:  A resource owner SHOULD assign a URI to 
each resource that others will expect to refer to.]]

This seems as if it should read "A resource owner SHOULD assign a URI to each resource that the owner expects others will want to refer to." (How can others expect to refer to resources they don't necessarily know about?)

Editorial concerning

2. Identification

Transition history

raised on 10 Mar 2004 by Frank Manola (fmanola@acm.org)

manola12: URI producers or owners? Relationship to opacity principle? Evidence of confusion about "agent" including "people"? [link to this issue]

[[URI producers should be conservative about the number of 
different URIs they produce for the same resource. For example, the 
parties responsible for weather.example.com should not use both 
"http://weather.example.com/Oaxaca" and 
"http://weather.example.com/oaxaca" to refer to the same resource; 
agents will not detect the equivalence relationship by following 
specifications. On the other hand, there may be good reasons for 
creating similar-looking URIs. For instance, one might reasonably create 
URIs that begin with "http://www.example.com/tempo" and 
"http://www.example.com/tiempo" to provide access to resources by users 
who speak Italian and Spanish.]]

Why does the first sentence refer to "URI producers" that "produce" URIs rather than "resource owners" that "create" them (which would be more consistent with earlier text). I also note that words "assign", "create", and "produce" (and possibly others) are all used for what seems to be the same idea.

Also, the rest of this illustration seems to have a funny interaction with the URI opacity principle in Section 2.5 (especially the discussion there about the travel example), since the Section 2.1 text above seems to suggest there is value in being able to convey information to an accessing "agent" (a human in this case) via the form of the URI itself (i.e., if URIs are to be totally opaque to the "agent", why would there be value in using one language over another?). Of course, this may be just another problem in allowing "agent" to refer to people. However, the problem seems somewhat more acute if the result of dereferencing URIs in different languages is the retrieval of the report in the corresponding languages because, while this kind of makes sense, it also invites determining the language of the report from the language of the URI.

Clarification concerning

• 2.1. URI Comparisons
• 2.5. URI Opacity

Transition history

raised on 10 Mar 2004 by Frank Manola (fmanola@acm.org)

manola13: Can agents assign URIs? Or should this be "use"? [link to this issue]

[[The requirement for URIs to be unambiguous demands that 
different agents do not assign the same URI...]]

Now we have *agents* assigning URIs rather than, e.g., resource or URI owners. It's not clear that this is consistent with prior discussion.

Clarification concerning

2.2. URI Ownership

Transition history

raised on 10 Mar 2004 by Frank Manola (fmanola@acm.org)

manola14: Clarify relationship between resource / URI ownership [link to this issue]

[[The concept of URI ownership is especially visible in the case of the 
HTTP protocol, which enables the URI owner to serve authoritative 
representations of a resource.]]

This text is pertinent to the point raised earlier about resource vs. URI ownership, and might be expanded on a bit to clarify that relationship. In particular, when dealing with URIs that have retrievable representations, it is straightforward to demonstrate ownership; non-owners can't determine what is returned when dereferencing such URIs, while owners can.

Clarification concerning

2.2. URI Ownership

Transition history

raised on 10 Mar 2004 by Frank Manola (fmanola@acm.org)

manola15: Does example *also* illustrate ambiguous URI usage? [link to this issue]

[[URI ambiguity should not be confused with ambiguity in 
natural language. The English statement "'http://www.example.com/moby' 
identifies 'Moby Dick'" is ambiguous because one could understand the 
phrase "Moby Dick" to refer to distinct resources: a particular printing 
of this work, or the work itself in an abstract sense, or the fictional 
white whale, or a particular copy of the book on the shelves of a 
library (via the Web interface of the library's online catalog), or the 
record in the library's electronic catalog which contains the metadata 
about the work, or the Gutenberg project's online version]]

This example illustrates an ambiguous natural language statement, but it's not clear that it doesn't also illustrate an ambiguous URI, since the text doesn't say anything about how example.org, or other parties citing http://www.example.com/moby, actually intepret it.

Clarification concerning

2.3. URI Ambiguity

Transition history

raised on 10 Mar 2004 by Frank Manola (fmanola@acm.org)

manola16: Paragraph on other uses of URIs is confusing [link to this issue]

[[In Web architecture, URIs identify resources. Outside 
the bounds of Web architecture specifications, URIs can be useful for 
other purposes, for example, as database keys...]]

It seems to me this paragraph mixes a few things. Just because a URI is used as a database key doesn't necessarily mean it's being used for a different purpose. If a URI is used as a key in a relational table that associates metadata with the Web resources identified by those keys, and does so correctly (i.e., distinguishes between metadata about Nadia and metadata about her mailbox), it seems as if this is the *same* use of the URI (to identify a Web resource), even though it may also be used in the database to identify a distinct row in the table. Moreover, the database might exhibit URI ambiguity in the same way the Web might, e.g., by mixing metadata about both Nadia and her mailbox in the same row. At the same time, the use of "mailto:nadia@example.com" as an identifier for Nadia rather than her mailbox seems just as likely to occur in a Web context as in this database one (people seem to want to do it in RDF, for example; or is this not the part of the Web you're talking about?).

Clarification concerning

2.3.1. URIs in other Roles

Transition history

raised on 10 Mar 2004 by Frank Manola (fmanola@acm.org)

manola17: "Agent" that includes "people" source of confusion [link to this issue]

[[It is tempting to guess the nature of a resource by 
inspection of a URI that identifies it. However, the Web is designed so 
that agents communicate resource state through representations, not 
identifiers.]]

This is another place where including people in the definition of "agents" seems to create a possible difficulty. If agents include people, then people quite frequently communicate information about the nature of a resource by inspection of URIs, and it's very helpful. For example, "http://weather.example.com/oaxaca" certainly suggests that the resource it identifies has something to do with the weather in oaxaca (as is noted further on), and that's very useful information (e.g., when people pass those URIs around). That's certainly information about "the nature of a resource", and Internet Media Types aren't the only things relevant to people. This all, of course, reads much better if "agents" are restricted to software. Pursuing this point in the subsequent text:

[[Agents making use of URIs MUST NOT attempt to infer properties of the 
referenced resource except as licensed by relevant specifications.]]

This is good practice for software "agents". For people "agents", given the "must not", how do you propose to stop them? Further to this point, the text goes on:

[[The example URI used in the travel scenario 
("http://weather.example.com/oaxaca") suggests that the identified 
resource has something to do with the weather in Oaxaca. A site 
reporting the weather in Oaxaca could just as easily be identified by 
the URI "http://vjc.example.com/315". And the URI 
"http://weather.example.com/vancouver" might identify the resource "my 
photo album."]]

This is certainly true. But while it's good practice for software to treat URIs opaquely, it seems to me that given the discussion in Section 2.1, which seems to license creating "descriptive" URIs in different languages to enable people speaking those languages to more easily access a resource (and which reflects the use of text in URIs as a means for conveying information to people), you might want to suggest that, given this "dual purpose" of URIs, it's *not* good practice to use the URI "http://weather.example.com/vancouver" to identify the resource "my photo album", even though one could, and it would be irrelevant to software.

Error concerning

2.5. URI Opacity

Transition history

raised on 10 Mar 2004 by Frank Manola (fmanola@acm.org)

Subsumed by issue(s) on 19 Jul 2004

Overtaken by events.

manola18: Update references to RDF, OWL specs [link to this issue]

Reference [RDF10] cites the RDF M&S Recommendation, rather than the new Recommendation set, and should be updated (the OWL reference should be updated as well). If *one* of the new RDF documents is to be cited, I would suggest Concepts.

Editorial concerning

6. References

Transition history

raised on 10 Mar 2004 by Frank Manola (fmanola@acm.org)

manola19: Please provide qualifying context about the nature of the Web [link to this issue]

[[Note that one can use a URI with a fragment identifier 
even if one does not have a representation available for interpreting 
the fragment identifier (one can compare two such URIs, for example). 
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.]]

This is a place where some qualifying context about the nature of the Web to which this architecture applies would have been helpful. For example, suppose I have a collection of RDF or OWL statements having as subjects the URI "http://www.example.com/images/nadia#hat", and the RDF/OWL statements assert that the subject is of class "Hat" in some ontology, that it's blue, and so on. On one hand, it seems as if one could reasonably draw conclusions about the interpretation of this fragment identifier (or rather the whole URI including it) *from the RDF/OWL* without dereferencing the URI (using the URI to retrieve a representation, whose media type specifies the authoritative interpretation), assuming that the RDF/OWL itself is from a sufficiently "authoritative" (in some sense) representation somewhere. Saying "such intepretations are not authoritative" without any further qualification or discussion, while it makes perfect sense given the way the Web works now, doesn't seem to take such additional usage (which, after all, is described in W3C Recommendations) into account.

Clarification concerning

3.3.1. Media Types and Fragment Identifier Semantics

Transition history

raised on 10 Mar 2004 by Frank Manola (fmanola@acm.org)

agreed on 13 May 2004

The TAG intends to clarify the text to indicate that parties who draw conclusions from syntactic analysis of URIs alone do so at their own risk.

Acknowledgment cycle

announced by group on 27 May 2004

Action history

manola20: Have text after a story answer the question in the story. [link to this issue]

It would be helpful if the text following the "story" explicitly answered the question posed in the "story". For example, if the idea here is that the fragment should always identify Nadia's hat in any graphic representation provided by dereferencing the URI containing the fragment, it would help to say that.

Editorial concerning

3.3.2. Fragment Identifiers and Multiple Representations

Transition history

raised on 10 Mar 2004 by Frank Manola (fmanola@acm.org)

manola21: Owner of resource v. owner of URI [link to this issue]

First para:  [[To give these parties the confidence that 
they are all talking about the same thing when they refer to "the 
resource identified by the following URI ..." the design choice for the 
Web is, in general, that the owner of a resource assigns the 
authoritative interpretation of representations of the resource.]]

The text "owner of a resource" links to Section 2.2 titled "URI Ownership". So why say "owner of a resource" rather than "owner of a URI"? Also, Section 3.3 just got through telling us that if the URI contains a fragment identifier, then the Internet Media Type of the retrieved representation specifies the authoritative interpretation of the fragment identifier. I realize that in one case it's the authoritative interpretation *of the fragment* and in the other its the authoritative interpretation *of representations of the resource*, but the use of "authoritative interpretation" in both places (particularly when they're so close together) seems potentially confusing.

Clarification concerning

3.4. Authoritative Representation Metadata

Transition history

raised on 10 Mar 2004 by Frank Manola (fmanola@acm.org)

manola22: "Agent" or "user agent" meant? [link to this issue]

[[User agents should detect such inconsistencies but 
should not resolve them without involving the user.]]

Now the term is "user agent" rather than "agents". Is there some particular reason for distinguishing between these terms?

Clarification concerning

3.4.1. Inconsistencies between Metadata and Representation Data

Transition history

raised on 10 Mar 2004 by Frank Manola (fmanola@acm.org)

manola23: Can software agents incur obligations? ("agent" or "user agent") [link to this issue]

[[Nadia's retrieval of weather information (an example of 
a read-only query or lookup) qualifies as a "safe" interaction; a safe 
interaction is one where the agent does not incur any obligation beyond 
the interaction. An agent may incur an obligation through other means 
(such as by signing a contract). If an agent does not have an obligation 
before a safe interaction, it does not have that obligation afterwards]]

Here, "agent" is used in a sense where it might well be a person ("signing a contract"). Can software agents "incur obligations" in the sense used here?

Clarification concerning

3.5. Safe Interactions

Transition history

raised on 10 Mar 2004 by Frank Manola (fmanola@acm.org)

manola24: What meaning(s) of "order" is meant? [link to this issue]

[[Other Web interactions resemble orders more than queries.]]

Is this "orders" in the sense of "placing an order", "that's an order, soldier", or both?

Clarification concerning

3.5. Safe Interactions

Transition history

raised on 10 Mar 2004 by Frank Manola (fmanola@acm.org)

manola25: Agents "do not" or "should not" incur obligations? [link to this issue]

[[Principle:  Safe retrieval
Agents do not incur obligations by retrieving a representation.]]

Shouldn't this be "should not" rather than "do not"? "Do not" suggests that it doesn't happen, rather than that it's incorrect if it does (as described in the next sentence).

Transition history

raised on 10 Mar 2004 by Frank Manola (fmanola@acm.org)

manola26: What does last sentence of story have to do with story? [link to this issue]

Following the story appears:
[[The usefulness of a resource depends on good management by its owner. 
As is the case with many human interactions, confident interactions with 
a resource depend on stability and predictability. The value of a URI 
increases with the predictability of interactions using that URI. 
Avoiding unnecessary URI aliases is one aspect of proper resource 
management.]]

While the last sentence above certainly seems true, it's not clear what it has to do with the story, since the sentence refers to URI aliases, but the story describes multiple uses of the *same* URI returning wildly different results. Is this supposed to refer to "URI ambiguity" instead? It's also not clear that the problem illustrated in the story is necessarily "inconsistent representation". Given the diagram in Section 1, which distinguishes the URI from the resource it identifies, it seems possible to distinguish (at least conceptually) between:

1. returning pages about weather information and auto insurance as inconsistent representations of the same resource, and
2. returning the same two pages as indicating that the URI owner has changed the resource the URI identifies

Editorial concerning

3.6. Representation Management

Transition history

raised on 10 Mar 2004 by Frank Manola (fmanola@acm.org)

manola27: Provide examples of mistaken attempts to restrict URI usage [link to this issue]

It might help clarify the point made in this section if some examples of mistaken attempts to restrict the use of URIs were given, rather than just the building security analogy. Also, it's not clear whether or not the principle described here (and the further discussion in the "Deep Linking" finding) deals with all possible situations of this sort. For example, it certainly used to be the case (and may be the case now) that US Defense Department documents could not only have a security classification, but their *titles* might also have a security classification (that is, the *existence* of the document was classified). A classified document with an unclassified title could be referenced in the usual way, but a reader without the necessary clearance would be unable to access the referenced document (this would correspond to the situations already described). On the other hand, classifying the title of the document would prevent the reader from even seeing the reference without the necessary clearance. How would you suggest handling this situation (admittedly, opagueness of URIs would help!)

Proposal concerning

3.6.3. Linking and Access Control

Transition history

raised on 10 Mar 2004 by Frank Manola (fmanola@acm.org)

manola28: Another case of "agent includes people?" doubt [link to this issue]

[[There is typically a (long) transition period during 
which multiple versions of a format, protocol, or agent are 
simultaneously in use.]]

This is another passage that reads strangely if "agent" is considered to include people (I know I'm not the same person I once was, but multiple versions simultaneously in use?!).

Editorial concerning

4.2.1. Versioning

Transition history

raised on 10 Mar 2004 by Frank Manola (fmanola@acm.org)

manola29: What are "language instances"? [link to this issue]

[[Good practice: Version information
Format designers SHOULD provide for version information in language 
instances]]

What are "language instances"?

Clarification concerning

4.2.1. Versioning

Discussion history

14 May 2004

Transition history

raised on 10 Mar 2004 by Frank Manola (fmanola@acm.org)

agreed on 14 May 2004

The TAG agreed to accept this change: "A format specification SHOULD provide for version information."

Acknowledgment cycle

announced by group on 27 May 2004

Action history

manola30: Difference between "setting expectations" and "specifying"? [link to this issue]

[[As part of defining an extensibility mechanism, a 
specification should set expectations about agent behavior in the face 
of unrecognized extensions.]]

The following good practice then says

[[Language designers SHOULD specify agent behavior in the face of 
unrecognized extensions.]]

It's not clear that a specification "setting expectations about" agent behavior is the same as it "specifying" it. Why the difference in wording?

Clarification concerning

4.2.3. Extensibility

Discussion history

14 May 2004

Transition history

raised on 10 Mar 2004 by Frank Manola (fmanola@acm.org)

agreed on 14 May 2004

Delete "As part of defining ..." sentence.

Acknowledgment cycle

announced by group on 27 May 2004

Action history

manola31: Questions about RDF, text, XML mixing [link to this issue]

Third bullet [[    * RDF allows well-defined mixing of 
vocabularies, and allows text and XML to be used as a data type values 
within a statement having clearly defined semantics.]]

"...allows text and XML to be used as data type values..." (delete the "a")?

Within the same statement? What does "having clearly defined semantics" modify? Should this be "...within statements having clearly defined semantics"?

Clarification concerning

4.2.4. Composition of Data Formats

Discussion history

14 May 2004

Transition history

raised on 10 Mar 2004 by Frank Manola (fmanola@acm.org)

agreed on 14 May 2004

The TAG believes this issue has been addressed by virtue of deletion of the text in question.

Acknowledgment cycle

announced by group on 27 May 2004

manola32: Reword to avoid rhetorical question [link to this issue]

[[How do the application designers ensure that there are 
no naming conflicts when they combine elements from different formats 
(for example, suppose that the "p" element is defined in two or more XML 
formats)?  "Namespaces in XML" [XMLNS] provides a mechanism for 
establishing a globally unique name that can be understood in any context.]]

I'd suggest rewriting this to avoid the rhetorical question.

Also, this may or may not be the right place to cite this example, but the way the XML Schema data types define a namespace for those types, allowing them to be used in RDF and OWL, might also be cited. (This example illustrates the need sometimes to explicitly describe how URIs identifying language elements should be constructed using those namespace names).

Editorial concerning

4.5.3. XML Namespaces

Transition history

raised on 10 Mar 2004 by Frank Manola (fmanola@acm.org)

qawg1: Seeking liaison on definitions of extensibility w.r.t. QA Guidelines [link to this issue]

At TP2004, one of the presentations referred to some material in WebArch about extensibility [1]. Karl Dubost started a Wiki topic about it [2], because QA also deals with extensibility in the QA Framework (QAF) [3].

In [1] and [3], TAG and QA might have slightly different concepts behind similar terminology, and/or might be implying slightly different advice. Even though the QAF is being radically revised and trimmed down, it seems clear now that extensibility is one of the topics that will almost certainly survive in a new, leaner Specification Guidelines.

At this point, QAWG would like to suggest some liaison or further detailed discussion during the revision of our respective documents, with a view towards making our respective extensibility-related content consistent. We could participate in a joint teleconference, or QAWG could prepare a detailed look at the respective extensibility bits, or both.

Transition history

raised on 15 Mar 2004 by Lofton Henderson (lofton@rockynet.com), on behalf of Quality Assurance Working Group

i18nwg1: Use "language" for natural language and "format" for format [link to this issue]

The term 'language' is used both for natural language (in the Abstract and for (document/data) format. In the later case, 'format' should be used everywhere, to avoid confusion. This would be the same as in Charmod.

Transition history

raised on 18 Mar 2004 by Martin Duerst (duerst@w3.org), on behalf of Internationalization Working Group

i18nwg2: Use "language" for natural language and "format" for format [link to this issue]

The term 'language' is used both for natural language (in the Abstract and for (document/data) format. In the later case, 'format' should be used everywhere, to avoid confusion. This would be the same as in Charmod.

Transition history

raised on 18 Mar 2004 by Martin Duerst (duerst@w3.org), on behalf of Internationalization Working Group

i18nwg2b: Oaxaca hard to pronounce; propose Lima [link to this issue]

'Oaxaca' is used in many examples. Glad to see a non-US example, but we are afraid that this may lead to questions on how to pronounce it in large parts of the world. We suggest to replace it with something simpler, one idea might be 'Lima' (although the weather is not as good there as in Oaxaca :-( ).

Transition history

raised on 18 Mar 2004 by Martin Duerst (duerst@w3.org), on behalf of Internationalization Working Group

i18nwg3: Please show charset in Content-type. [link to this issue]

section 1, figure: please show charset in Content-type.

Editorial concerning

1. Introduction

Transition history

raised on 18 Mar 2004 by Martin Duerst (duerst@w3.org), on behalf of Internationalization Working Group

i18nwg4: Please refer to "issues" rather than "limitations" [link to this issue]

First bullet: This and http://www.w3.org/2001/tag/doc/whenToUseGet.html#i18n are basically okay. However the word 'limitations' (related to i18n) may give the wrong impression; it is not clear what the i18n concerns are. We suggest that you describe the issue more clearly, e.g. as "The design works reasonably well, although there are issues related to the transmission of non-ASCII characters." (please note the use of the word 'issues' rather than 'limitations'; although there are indeed some limitations as to the combinations of encodings in form pages and in requests, due to well-established practices based on HTML 4, there is no fundamental limitation to the basic use of non-ASCII characters. Also, please make sure the reader can directly go to the relevant section in the finding. Also, you may want to point to the FAQ on "What is the best way to deal with encoding issues in forms that may use multiple languages and scripts?" http://www.w3.org/International/questions/qa-forms-utf-8.html

Clarification concerning

1.2.1. Orthogonal Specifications

Transition history

raised on 18 Mar 2004 by Martin Duerst (duerst@w3.org), on behalf of Internationalization Working Group

i18nwg5: Discussion of content-type header hint [link to this issue]

Third bullet:

"Some authors use the META/http-equiv approach
     to declare the character encoding scheme of an HTML document. By
     design, this is a hint that an HTTP server should emit a corresponding
     "Content-Type" header field. In practice, the use of the hint in servers
    is not widely deployed. Furthermore, many user agents use this information
    to override the "Content-Type" header sent by the server. This works
    against the principle of authoritative representation metadata."

This is rather misleading on several points:

• "By design, this is a hint that an HTTP server should emit a corresponding "Content-Type" header field.": It's correct that by design, this WAS a hint to the sever. Practice has shown that this wasn't such a good idea, and practice has found a better use for it. The WebArch doc should mainly look forward, mentioning misguided/reused designs can help, but it should not be presented as if it would be better to go back to that design. So e.g. reword to "this was (originally) intended..."
• "In practice, the use of the hint in servers is not widely deployed.": Is it actually deployed at all? Any pointers would be appreciated.
• "Furthermore, many user agents use this information to override the "Content-Type" header sent by the server.": Tests we have done recently with reasonably new browsers have shown that none of the major browsers do this. In particular if 'many user agents' is an acronym for IE6win, this is actually wrong (in case you do you own tests, please clean your cache if you change encodings or encoding labels for files; encodings are very 'sticky' in IE6, but for fresh pages, it gets things right). We suggest rewording e.g. to "user agents use this information if there is no 'charset' information in the "Content-Type" header" and/or "some have in the past..."

Error concerning

1.2.1. Orthogonal Specifications

Transition history

raised on 18 Mar 2004 by Martin Duerst (duerst@w3.org), on behalf of Internationalization Working Group

i18nwg6: Say something about character encoding/labeling errors. [link to this issue]

Error Handling: It might be very good to say something about character encoding/labeling errors.

Editorial concerning

1.2.3. Error Handling

Transition history

raised on 18 Mar 2004 by Martin Duerst (duerst@w3.org), on behalf of Internationalization Working Group

i18nwg7: Mention language negotiation [link to this issue]

Just before 2.1:

 "Of course, what an agent does with a URI
     may vary."

It would be better to mention more explicitly that this e.g. can include language negotiation,...

Editorial concerning

2. Identification

Transition history

raised on 18 Mar 2004 by Martin Duerst (duerst@w3.org), on behalf of Internationalization Working Group

i18nwg8: Sentences seem contradictory [link to this issue]

2nd para. The first sentence establishes that character-by-character inequality doesn't mean that the resource referred is different. But the subsequent sentences say basically the opposite (that this is the most straightforward way to find resource equality). Break into two paragraphs, or otherwise improve wording to less confuse the reader.

Error concerning

2.1. URI Comparisons

Transition history

raised on 18 Mar 2004 by Martin Duerst (duerst@w3.org), on behalf of Internationalization Working Group

Subsumed by issue(s) on 9 Aug 2004

Overtaken by events.

Action history

i18nwg9: Case example unclear. [link to this issue]

3rd para. The casing example for weather.example.com/Oaxaca is a bit obscure. Perhaps spell out the fact that case sensitivity matters to some systems?

Clarification concerning

2.1. URI Comparisons

Transition history

raised on 18 Mar 2004 by Martin Duerst (duerst@w3.org), on behalf of Internationalization Working Group

i18nwg10: Don't recommend organizing information by language. [link to this issue]

For instance, one might reasonably create URIs that begin with
      "http://www.example.com/tempo" and "http://www.example.com/tiempo" to
      provide access to resources by users who speak Italian and
      Spanish."

It is nice to see an i18n-related example. However, there are all kinds of issues with this. This is not necessarily a good way to organize information in different languages on a server, in particular if the information is highly parallel. It may be better to find another example, for example with two English words. Also, 'tempo' is an English word with a different meaning. Perhaps German "Wetter" is better?

Clarification concerning

2.1. URI Comparisons

Transition history

raised on 18 Mar 2004 by Martin Duerst (duerst@w3.org), on behalf of Internationalization Working Group

Action history

i18nwg11: Mention IRIs? [link to this issue]

4th para.

"Likewise, URI consumers should ensure URI
      consistency. For instance, when transcribing a URI, agents should not
      gratuitously escape characters. The term "character" refers to URI
      characters as defined in section 2 of [URI]".

The definition of 'character' in the first sentence is not clarified by section 2 of the URI draft, which deals with details such as percent escaping of characters. Section 1 of the URI draft *points to* a definition of 'character'. This is an area where the presence of IRI would be welcome. It might be more useful to describe what "gratuitious" means in this context (there is currently no definition; we *think* it means "don't escape characters unless it breaks usability", i.e. I would expect to see %20 instead of space (because space breaks the URI semantically).

Clarification concerning

2.1. URI Comparisons

Transition history

raised on 18 Mar 2004 by Martin Duerst (duerst@w3.org), on behalf of Internationalization Working Group

i18nwg12: Clarification on reference to "character" [link to this issue]

'The term "character"...': please say instead: 'The term "character" in the foregoing sentence...' (character takes on other meanings later...)

Editorial concerning

2.1. URI Comparisons

Transition history

raised on 18 Mar 2004 by Martin Duerst (duerst@w3.org), on behalf of Internationalization Working Group

i18nwg13: URI ambiguity ambiguous [link to this issue]

para 2. Shouldn't there be a "but..." at the end of this paragraph? Yes, URI ambiguity is not the same thing as natural language ambiguity... but what is it? Please make the example more direct:

"URI ambiguity should not be confused with ambiguity
      in natural language. The English statement
      "'http://www.example.com/moby' identifies 'Moby Dick'" is
      ambiguous because one could understand the phrase "Moby Dick" to
      refer to distinct resources: a particular printing of this work,..."

This is highly ambiguous (sic!). Is 'http://www.example.com/moby' identifies 'Moby Dick' a statement in natural language, showing how natural language can be ambiguous? Or is it a statement about an URI, showing how URis can be ambiguous? Better change to say: "The URI http://www.example.com/moby is used ambiguously if it is used for more than one of the following: a particular printing of this work,..."

Editorial concerning

2.3. URI Ambiguity

Transition history

raised on 18 Mar 2004 by Martin Duerst (duerst@w3.org), on behalf of Internationalization Working Group

i18nwg14: Show examples of good and bad ambiguity [link to this issue]

URI ambiguity. This may imply or suggest that natural language differences in the representation of a resource are considered bad. There should be examples of both good and bad ambiguity (or in WebArch terminology, different but consistent representations of the same resource as opposed to the use of a single URI for different resources), with language negotation being a good example and wholly different resources being a bad example

Clarification concerning

2.3. URI Ambiguity

Transition history

raised on 18 Mar 2004 by Martin Duerst (duerst@w3.org), on behalf of Internationalization Working Group

i18nwg15: Missing word [link to this issue]

Missing a word in "URI ambiguity arises >>when<< (or 'as') a URI is used to identify two different Web resources.

Editorial concerning

2.3.1. URIs in other Roles

Transition history

raised on 18 Mar 2004 by Martin Duerst (duerst@w3.org), on behalf of Internationalization Working Group

i18nwg16: Good practice on URI opacity impossible to follow for humans. [link to this issue]

Good practice: URI opacity: This says
      "Agents making use of URIs MUST NOT attempt to infer properties of the
      referenced resource except as licensed by relevant specifications."
      Earlier, the document defines 'agent' as both humans and machines.

This good practice is not too difficult to follow for agents (although this seems to disallow e.g. Google to consider pieces of an URI in their algorithms, e.g. the 'weather' and 'oaxaca' in 'http://weather.example.com/oaxaca'; we're not sure disallowing this is intended or makes sense).

However, this practice is *impossible* to follow for humans: It's just completely impossible to look at http://weather.example.com/oaxaca and NOT interfering that this may be about 'weather' or 'oaxaca'. The WebArch document itself is using this connection all the time. This is important in connection with IRIs.

Error concerning

2.3.1. URIs in other Roles

Transition history

raised on 18 Mar 2004 by Martin Duerst (duerst@w3.org), on behalf of Internationalization Working Group

Subsumed by issue(s) on 19 Jul 2004

Overtaken by events.

i18nwg17: Add mention of IRIs [link to this issue]

List item 2: "The XLink 1.0 [XLink10] specification, which defines
      the href attribute in section 5.4, states that "The value of the href
      attribute must be a URI reference as defined in [IETF RFC 2396], or must
      result in a URI reference after the escaping procedure described below
      is applied.""

This refers to the conversion from an IRI to an URI. It would be a good occasion to mention IRIs.

Editorial concerning

3.1. Using a URI to Access a Resource

Transition history

raised on 18 Mar 2004 by Martin Duerst (duerst@w3.org), on behalf of Internationalization Working Group

i18nwg18: Mention that editing tools may be more strict than simple user agents [link to this issue]

Maybe mention that editing tools may be more strict than simple user agents.

Editorial concerning

3.4.1. Inconsistencies between Metadata and Representation Data

Transition history

raised on 18 Mar 2004 by Martin Duerst (duerst@w3.org), on behalf of Internationalization Working Group

i18nwg19: text/foo+xml considered useless? [link to this issue]

We believe that charset handling, the way it is currently specified in various specs (i.e. outer information has priority to inner information), is basically okay (with the exception of the (irrelevant in practice) iso-8859-1 default given in the HTTP spec, and the us-ascii default for text/foo+xml, which makes text/foo+xml rather useless. It might be good to reach some consensus about this, and document it.

Proposal concerning

3.4.1. Inconsistencies between Metadata and Representation Data

Transition history

raised on 18 Mar 2004 by Martin Duerst (duerst@w3.org), on behalf of Internationalization Working Group

Subsumed by issue(s) on 19 Jul 2004

Overtaken by events.

i18nwg20: text/foo+xml considered useless? [link to this issue]

"Furthermore, server managers can help reduce the
      risk of error through careful assignment of representation metadata
      (especially that which applies across representations). The section
      on media types for XML presents an example of reducing the risk of
      error by providing no metadata about character encoding when serving
      XML."

This seems to pick out a somewhat arbitrary detail, without stating the much more important underlying principles, such as:

• Always make sure you know what the character encoding of a document or message is.
• Make sure that it's easy for server managers and authors to configure and test metadata on the server, to make sure it's correct.
• No arbitrary defaults for specs
• No out-of-the-box with arbitrary settings The description of the example also is too general, because there are ways to implement/operate a server that make it much more easy/appropriate to put the 'charset' into the header than into the body, e.g. when producing content in a pipeline from a database.

Proposal concerning

3.4.1. Inconsistencies between Metadata and Representation Data

Transition history

raised on 18 Mar 2004 by Martin Duerst (duerst@w3.org), on behalf of Internationalization Working Group

rdfcore1: RDF Core general comments [link to this issue]

In response to the call for review of [1], several members of the RDFCore WG have submitted many detailed comments on the document [2][3][4][5] which we hope the TAG will find useful. We are confident the TAG will give due consideration to each comment on its merits with or without specific endorsement by the RDFCore WG. RDFCore requests, however, that the tag pay particular attention to comments that relate to:

• having a clear vocabulary and meaning for fundamentatal notions such as resource, representation, naming, identifying etc.
• reference and dentotation and other forms of use of URIs with and without fragment identifiers
• allowing URIs that identify resources such as people that are not 'on the web'
• notions of authority and ownership of URIs and resources

We trust that the citation of the RDF Model and Syntax specification be replaced with a citation of the new RDF Concepts and Abstract Syntax document [6] in due course.

Transition history

raised on 24 Mar 2004 by McBride, Brian (brian.mcbride@hp.com), on behalf of RDF Core Working Group

dubinko1: Document different interpretations around httpRange-14 [link to this issue]

Jonathan Borden wrote:

I am not sure it is emprically possible to decide which of the above two
types of representation are correct (i.e. I think both are correct under
specific circumstances)

That hits the nail on the head. The webarch document would be much more useful if it explained the two or so commonly held interpretations of Web architecture rather than trying to explain away all but one.

At the level of code, the Web just works, as always. But at the level of web developers making decisions about how to allocate URIs and so on, interpretations are the deciding factor.

If I write an HTTP server, and think of it as serving byte ranges of specific files, that's OK.

If I use a URI to make assertions about a remote galaxy, that's OK too.

The webarch document needs to document these interpretations.

Editorial concerning

2. Identification

Transition history

raised on 21 Jul 2003 by Micah Dubinko (MDubinko@cardiff.com)

dubinko2: Architecture v. Building Codes [link to this issue]

I've been following most of the TAG discussions. Often there are several possible interpretations for some aspect under discussion, and often there is no empirical way to decide which one is correct. Both can be correct under specific circumstances. Such is the nature of any "architecture".

An amazing amount of work has gone into the webarch document. Good work. Still it fails to describe what could be called an architecture.

The document in question reads more like "building codes", the sort of things that can be universally agreed upon, and concretely argued. A room full of brilliant architects, however, will just never agree on a single design for anything non-trivial. Each will have a different philosophy on how things should be described, and each a unique approach.

In other words, the W3C consensus process (wildly successful as it is in many areas) is fundamentally the wrong way to write down "the Web architecture".

Some concrete suggestions for changes:

1. Retitle the document. It isn't an "architecture" document as it stands. I suggest using a synonym for "building codes".
2. Change the Abstract and Status of this document to indicate that the scope of this particular document is things that achieved consensus within the TAG
3. Commit to better layering through one or more follow-on documents that describe a particular architectural philosophy. In particular, REST. It's possible that such documents could produce dissentions. If the dissention affects running code, it should be resolved in the "building codes" document. If it doesn't affect code, it's a legitimate difference and should be allowed to stand. A significant body of dissenting philosophy should warrant a separate document to espouse the alternate view.
4. In particular, the following open issues would lend themselves to this kind of resolution: (not an exhaustive list)
5. Remove any non-provable statements from the document, including "Resources exist before URIs; a resource may be identified by zero URIs" (sec 2) There may be others.

Transition history

raised on 26 Mar 2004 by Micah Dubinko (MDubinko@verity.com)

falstrom1: Editorial comments [link to this issue]

Reviewer observed that:

• The document is long.
• There is no mention of WebDav.

Reviewer suggested that:

• Good practice notes be numbered
• s/Internet Media Types/Media Types

Editorial concerning

6. References

Transition history

raised on 21 Apr 2004 by Patrick Falstrom, on behalf of Internet Architecture Board

falstrom2: SOAP as a different thing than the other protocols [link to this issue]

The document list SOAP beside HTTP, FTP, NNTP and SMTP but the IETF see 
SOAP as a different thing than the other protocols as everyone else is 
transported on TCP while SOAP need some more "things" between TCP and 
SOAP. Normally, SOAP is transported on HTTP, SMTP or BEEP according to 
various specifications. This might be confusing for the reader if it is 
not clarified.

Clarification concerning

3.2. Messages and Representations

Transition history

raised on 21 Apr 2004 by Patrick Falstrom, on behalf of Internet Architecture Board

falstrom3: Separate Media Types and Frag Id discussion [link to this issue]

The section talks about Internet Media Type and Fragment Identifiers. 
These are two orthogonal things. The selection of media type for a 
resource is one thing, and potential use of fragment identifier another.

It would be good if the statement about Fragment identifier consistency 
was independent from the Fragment Identifier issues, because this 
statement should be general for a URI. Potentially it should be moved to 
the section earlier which talks about eqvivalence of URI's.

This is described somewhat in section 3.6 but...

Editorial concerning

3.3.2. Fragment Identifiers and Multiple Representations

Transition history

raised on 21 Apr 2004 by Patrick Falstrom, on behalf of Internet Architecture Board

falstrom4: Show only good practice re: Content-Location [link to this issue]

It would be better if the stories only talked about how a web server 
should behave, and not show bad behaviour. In this case (the story 
directly below 3.5.1), it should say Content-Location header is used.

Editorial concerning

3.5.1 Unsafe Interactions and Accountability

Transition history

raised on 21 Apr 2004 by Patrick Falstrom, on behalf of Internet Architecture Board

falstrom5: Add discussion about SSL/TLS? Is title correct? [link to this issue]

The title of the section implies the section will talk about "unsafe 
transactions" which to some readers might imply also discussion about 
use of SSL/TLS. I would recomment a new title as the section more talks 
about "stability and ability to bookmark" URI's.

Editorial concerning

3.5.1 Unsafe Interactions and Accountability

Transition history

raised on 21 Apr 2004 by Patrick Falstrom, on behalf of Internet Architecture Board

falstrom6: List overall diffs between binary and text formats [link to this issue]

It would be good if the overall differences between binary and textual 
data formats were listed, the most important one being the linebreak 
changes on textual data which in turn might make signing of data 
difficult/different.

Editorial concerning

4.1 Binary and Textual Data Formats

Transition history

raised on 21 Apr 2004 by Patrick Falstrom, on behalf of Internet Architecture Board

falstrom7: Indicate when to use different link types [link to this issue]

The three (!) different link types have different meaning, and it should 
be spelled out when to use which.

Editorial concerning

4.4 Hypertext

Transition history

raised on 21 Apr 2004 by Patrick Falstrom, on behalf of Internet Architecture Board

rosenberg1: Introductory para on Web overly broad? [link to this issue]

The World Wide Web (WWW, or simply Web) is an information space in which the items of interest, referred to as resources, are identified by global identifiers called Uniform Resource Identifiers (URIs).

Thats a pretty broad definition; as it would include resources defined
by other URI schemes (such as sip and tel) which I don't think are
normally associated with the "web". The intent of the document, I think,
is to generally think about resources that correspond to content.

Editorial concerning

Introduction

Transition history

raised on 21 Apr 2004 by Jonathan Rosenberg, on behalf of Internet Architecture Board

rosenberg2: RFC2119 terms meant for protocols [link to this issue]

The terms MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY are used in the good practice notes, principles, etc. in accordance with RFC 2119 [RFC2119]. However, this document does not include conformance provisions for at least these reasons:

This may be a nit, but RFC2119 is really meant to be applicable to
protocol specifications, not practices and principles.

Editorial concerning

About This Document

Transition history

raised on 21 Apr 2004 by Jonathan Rosenberg, on behalf of Internet Architecture Board

rosenberg3: Reuse appropriate URI schemes (and protocols) [link to this issue]

Authors of specifications SHOULD NOT introduce a new URI scheme when an existing scheme provides the desired properties of identifiers and their relation to resources

The inverse (converse?) is also true - you should reuse a scheme and
protocol when they
do have the desired properties. It might be a good idea to reference
RFC3205 in this regard.

Proposal concerning

URI Schemes

Transition history

raised on 21 Apr 2004 by Jonathan Rosenberg, on behalf of Internet Architecture Board

Subsumed by issue(s) on 19 Jul 2004

Overtaken by events.

rosenberg4: Use SIP for voice-over-ip, RTSP for streaming media [link to this issue]

There remain open questions regarding Web interactions. The TAG expects future versions of this document to address in more detail the relationship between the architecture described herein, ... voice-over-ip (including RTSP [RFC2326]).

RTSP does not qualify as voice over IP by most people's definitions. Its 
generally called "streaming media", and if you want to reference a VoIP 
protocol, try SIP (RFC 3261).

Clarification concerning

3.7. Future Directions for Interaction

Transition history

raised on 21 Apr 2004 by Jonathan Rosenberg, on behalf of Internet Architecture Board

rosenberg5: Proposed reference to IANA registry for namespaces and RFC 3688 [link to this issue]

IETF has established an IANA registry for namespaces, so as to guarantee 
uniquess. It might be worth referencing the specification that creates 
this registry, RFC 3688.

Editorial concerning

4.5.3 XML Namespaces

Transition history

raised on 21 Apr 2004 by Jonathan Rosenberg, on behalf of Internet Architecture Board

agreed on 8 Aug 2004

Classified as editorial, addressed by the editor. Added the ref.

Acknowledgment cycle

Not started