Change history for Architectural Principles of the World Wide Web

- In section 4.2.3, deleted "As part of defining an extensibility
mechanism, specification designers should set expectations about agent
behavior in the face of unrecognized extensions."
----------------------------
revision 1.602
date: 2004/06/07 03:00:51; author: ijacobs; state: Exp; lines: +2 -3
Per http://www.w3.org/2004/05/14-tag-summary.html,
for issue http://www.w3.org/2001/tag/2003/lc1209/issues.html#manola29

GPN now reads:

A data format specification SHOULD provide for version information.
----------------------------
revision 1.601
date: 2004/06/07 02:58:01; author: ijacobs; state: Exp; lines: +12 -5
Per http://www.w3.org/2004/05/14-tag-summary.html,
for issue http://www.w3.org/2001/tag/2003/lc1209/issues.html#diwg4,

Added para to section 3.3:

"Internet media type mechanism does have its limitations. For
instance, media type strings do not support versioning
or other parameters. The TAG issue
mediaTypeManagement-45
concerns the appropriate level of granularity of the media type
mechanism."
----------------------------
revision 1.600
date: 2004/06/07 02:52:25; author: ijacobs; state: Exp; lines: +12 -6
Per http://www.w3.org/2004/05/14-tag-summary.html,
in section 4 tried to talk about protocol extensibility
in section 1.2
----------------------------
revision 1.599
date: 2004/06/07 02:38:50; author: ijacobs; state: Exp; lines: +3 -3
Per http://www.w3.org/2004/05/14-tag-summary.html,
for issue

- Deleted "falling back to default behavior" in section
"Extensibility"
----------------------------
revision 1.598
date: 2004/06/07 02:36:23; author: ijacobs; state: Exp; lines: +2 -2
Per http://www.w3.org/2004/05/14-tag-summary.html,
In section 4, first sentence,
changed order to "XHTML, RDF/XML, SMIL, XLink, CSS and PNG" per
suggestion from MJ.
----------------------------
revision 1.597
date: 2004/06/07 02:35:11; author: ijacobs; state: Exp; lines: +1 -3
Per http://www.w3.org/2004/05/14-tag-summary.html,
change text in 2.7 to "peer-to-peer systems.
----------------------------
revision 1.596
date: 2004/06/07 02:32:32; author: ijacobs; state: Exp; lines: +3 -2
Per http://www.w3.org/2004/05/14-tag-summary.html,
In 2.2, changed sentence about delegation to read:

"This document does not address how the benefits and responsibilities
of URI ownership may be delegated to other parties, such as to a
server manager or to someone who has been delegated part of the URI
space on a given Web server."
----------------------------
revision 1.595
date: 2004/06/07 02:31:07; author: ijacobs; state: Exp; lines: +3 -2
Per http://www.w3.org/2004/05/14-tag-summary.html,
In 3.6.2:
s/authorities servicing URI/URI owner/
----------------------------
revision 1.594
date: 2004/06/07 02:29:58; author: ijacobs; state: Exp; lines: +2 -1
Per http://www.w3.org/2004/05/14-tag-summary.html,
added for 3.6.1:

"there is a benefit to the community in providing representations."
----------------------------
revision 1.593
date: 2004/06/07 02:27:38; author: ijacobs; state: Exp; lines: +1 -1
Per http://www.w3.org/2004/05/14-tag-summary.html,
s/unpredictable/unreliable or unpredictable/
----------------------------
revision 1.592
date: 2004/06/07 01:43:17; author: ijacobs; state: Exp; lines: +17 -27
Per http://www.w3.org/2004/05/14-tag-summary.html,
simplified discussion in 3.5.1 and distinguished transaction requests
from results.
----------------------------
revision 1.591
date: 2004/06/07 01:25:52; author: ijacobs; state: Exp; lines: +2 -4
Deleted:

Note that even though the response to an HTTP POST request may
contain a representation, the response to an HTTP POST request is not
necessarily a representation of the resource identified in the POST
request.

From earlier section since looks like it will fit in 3.5.1
----------------------------
revision 1.590
date: 2004/06/07 01:24:10; author: ijacobs; state: Exp; lines: +3 -2
Per http://www.w3.org/2004/05/14-tag-summary.html,
in 3.5:

added "necessarily" to "the word "unsafe" does not
necessarily mean "dangerous";

s/results/requests in "It is a breakdown of the Web architecture if
agents cannot use URIs to reconstruct a "paper trail" of transaction
requests,"
----------------------------
revision 1.589
date: 2004/06/07 01:22:23; author: ijacobs; state: Exp; lines: +1 -1
chnaged title of GPN in 3.4
----------------------------
revision 1.588
date: 2004/06/07 01:21:40; author: ijacobs; state: Exp; lines: +79 -80
Per http://www.w3.org/2004/05/14-tag-summary.html, significant
edits to 3.4 and 3.4.1:

- New title: Inconsistencies between Representation Data and Metadata
- New first para.
- No more discussion of "authoritative metadata"
- Added example of html + text/plain as not being an inconsistency.
----------------------------
revision 1.587
date: 2004/06/07 00:21:27; author: ijacobs; state: Exp; lines: +68 -59
Per http://www.w3.org/2004/05/14-tag-summary.html, significant
edits to 3.3.2. Fragment Identifiers and Multiple Representations:

- New title: Fragment Identifiers and Content Negotiation
- Defined coneg up front.
- Per ftf meeting, cited three possible outcomes (consistent,
inconsistent, defined in only one spec).
- Distinguish server management error from error on agent
side in case three.
- Refer to CUAP in case there.
- Removed story.
- Removed GPN.
- Removed reference to httpRange-14
----------------------------
revision 1.586
date: 2004/06/06 23:23:39; author: ijacobs; state: Exp; lines: +7 -15
Per http://www.w3.org/2004/05/14-tag-summary.html, edits
in 3.6.2. URI Persistence:

Removed bulleted list. Now talk about inconsistency, and that
defined from perspective of representation provider (or URI
owner).
----------------------------
revision 1.585
date: 2004/06/06 23:07:25; author: ijacobs; state: Exp; lines: +1 -1
Per http://www.w3.org/2004/05/14-tag-summary.html, in 3.3.2:
s/SHOULD NOT/MUST NOT in GPN
----------------------------
revision 1.584
date: 2004/06/06 23:00:44; author: ijacobs; state: Exp; lines: +6 -5
Per http://www.w3.org/2004/05/14-tag-summary.html, edits in 3.3.1:

- Edited the sentence "Parties that draw" to be about syntactic
analysis rather than representations.

- n story, section 3, deleted "by /satimage/oaxaca".
----------------------------
revision 1.583
date: 2004/06/06 22:53:38; author: ijacobs; state: Exp; lines: +10 -10
Per http://www.w3.org/2004/05/14-tag-summary.html, edits in 3.3.1:

- Remove "during a retrieval action" in penultimate para.
- Delete from "Note..." to end of same paragraph.

HOWEVER:

I think that the point made at the ftf meeting that a
resource can be both a primary and secondary resource is
worth making, so I made it at end of section.
----------------------------
revision 1.582
date: 2004/06/06 22:47:25; author: ijacobs; state: Exp; lines: +11 -6
Per http://www.w3.org/2004/05/14-tag-summary.html,

Added:

Combined it in OL in 3.3.1 with:

All Information Resources are primary resources.
----------------------------
revision 1.580
date: 2004/06/06 22:40:22; author: ijacobs; state: Exp; lines: +21 -23
Editorial: moved example of dereference (SVG) to own subsection.
----------------------------
revision 1.579
date: 2004/06/06 22:31:44; author: ijacobs; state: Exp; lines: +64 -85
more editing about info resources, some based on:
----------------------------
revision 1.578
date: 2004/06/06 22:07:05; author: ijacobs; state: Exp; lines: +54 -28
starting to incorporate Information resource (new section near
beginning of 4) and also that all Info Resources are primary
resources.
----------------------------
revision 1.574
date: 2004/06/06 21:14:19; author: ijacobs; state: Exp; lines: +0 -11
Per http://www.w3.org/2004/05/14-tag-summary.html,
deleted third para.
----------------------------
revision 1.572
date: 2004/06/06 21:13:04; author: ijacobs; state: Exp; lines: +8 -7
Moved a para about multiple reprs. from different URI owners
form 2.7.2 to 2.3 since not specific to sem web technologies.
----------------------------
revision 1.571
date: 2004/06/06 21:08:15; author: ijacobs; state: Exp; lines: +5 -2
Some edits to sentence on delection of URI ownership authority.
----------------------------
revision 1.570
date: 2004/06/06 21:05:00; author: ijacobs; state: Exp; lines: +7 -6
Per http://www.w3.org/2004/05/14-tag-summary.html,

Section 2.3:

- Added "For example, " before ". When the HTTP protocol is used to
provide representations, the HTTP origin server (defined in
[RFC2616]) is the software agent acting on behalf of the URI
owner."

- Moved previous sentence to section on authoritative metadata.

Section 2.4:

- Removed "normative" in first para.
----------------------------
revision 1.569
date: 2004/06/05 01:18:24; author: ijacobs; state: Exp; lines: +28 -17
Per http://www.w3.org/2004/05/14-tag-summary.html, rewrite of 2.2.2
in terms of indirect identification. Included rhetorical analogy.
Also included this attempt at a definition, taken from RF comments:

"A URI acts as an indirect identifier when it is a component
in a string of references that, taken together, identify
something."
----------------------------
revision 1.568
date: 2004/06/05 00:34:46; author: ijacobs; state: Exp; lines: +32 -28

Per http://www.w3.org/2004/05/14-tag-summary.html,
recast GPN 2.2:

Avoiding URI Overloading: Agents SHOULD find out what resource a URI
identifies before using that URI.

removed from 2.2:

"In many contexts, inconsistent use may not lead to error or cause
harm. However, in some contexts such as the Semantic Web, much of the
value of a relies on consistent use of URIs."

The Semantic Web does not fail in the face of inconsistency, though its
value certainly increases with consistent usage.
----------------------------
revision 1.567
date: 2004/06/05 00:09:26; author: ijacobs; state: Exp; lines: +1 -1
RFC2396bis uses the term "percent-encode" instead of "escape"; that
change was made here as well.
----------------------------
revision 1.566
date: 2004/06/05 00:08:56; author: ijacobs; state: Exp; lines: +18 -26
Deleted this example from 2.1.1 since it is NOT about URI Aliases;
these URIs identify different resources.

-Publish a URI (such as "http://www.example.com/")
for a resource with multiple representations in
different human languages. Agents use content negotiation to select a
representation of this resource according to user preferences for
language.

- Publish one URI per available language of the previous resource,
such as "http://www.example.com/tempo" (the Italian resource)
and "http://www.example.com/tiempo" (the Spanish resource).

One may wish to refer to the language-independent resource or to a
language-specific resource; they are all different resources
identified by different URIs.
----------------------------
revision 1.565
date: 2004/06/04 23:49:34; author: ijacobs; state: Exp; lines: +2 -6
removed more oaxaca example from 2.1.1
----------------------------
revision 1.564
date: 2004/06/04 23:48:11; author: ijacobs; state: Exp; lines: +18 -28
Per http://www.w3.org/2004/05/14-tag-summary.html, in section 2.1,
removed two http URI examples, leaving instead a reference to
section 6 of [URI].
----------------------------
revision 1.563
date: 2004/06/04 23:44:00; author: ijacobs; state: Exp; lines: +2 -2
In 2.1:

s/false negative comparision/false negative

same for positive
----------------------------
revision 1.561
date: 2004/06/04 23:42:22; author: ijacobs; state: Exp; lines: +4 -9
Per http://www.w3.org/2004/05/14-tag-summary.html, deleted
the "URI multiplicity" constraint from the beginning of 2.1. This
text was moved (as an ordinary sentence) to the new subsection:
URI/Resource Relationships.
----------------------------
revision 1.560
date: 2004/06/04 23:40:10; author: ijacobs; state: Exp; lines: +1 -1
editorial: removed an instance of "people" where not necessarily people.
----------------------------
revision 1.559
date: 2004/06/04 23:39:11; author: ijacobs; state: Exp; lines: +120 -64
Per http://www.w3.org/2004/05/14-tag-summary.html, a number
of changes to the beginning of sections 2 and 2.1.

- Replaced initial constraint with a new principle and a new
GPN:

Principle:

Global Identifiers: Global naming leads to global network
effects.

GPN:

Identify with URIs: To benefit from and increase the value of
the World Wide Web, agents should provide URIs as identifiers for
resources.

- Created a new subsection specifically about the benefits
of the URI mechanism. Moved subsequent text up to that section.

- Introduced a little more text about "other mechanisms" for
identifying resources, with some forward links. Also about
the costs of new mechanisms that replicate URIs.

- Created a new subsection about URI/Resource Relationships that
states clearly:
- URI identifies one resource.
- More than one URI may identify same resource.

Also provided a little (new) rationale for each of those
constraints.

- In that subsection, asked some frequently asked questions with
forward pointers to sections with discussion about the
answers. In particular, tried to address the question of
whether resource can have zero identifiers by saying (a) in
world with only URIs, doesn't matter and (b) with advent
of other systems, might change.

- This simplified the initial discussion of 2.1; in second paragraph,
added last sentence about generally higher cost of determining
whether two different URIs identify the same resource.

- Also trying to introduce more 'pro and con' discussion per the
ftf meeting.

- Other text (e.g., on format network effects) was moved to
other sections.
----------------------------
revision 1.558
date: 2004/06/03 23:33:37; author: ijacobs; state: Exp; lines: +2 -2
tweak re: 404 (not found)
----------------------------
revision 1.557
date: 2004/06/03 23:32:55; author: ijacobs; state: Exp; lines: +39 -24
Per http://www.w3.org/2004/05/14-tag-summary.html, in section 1.2.3,
distinguish error correction from error recovery. Related issues:

----------------------------
revision 1.556
date: 2004/06/03 22:17:19; author: ijacobs; state: Exp; lines: +6 -5
Per http://www.w3.org/2004/05/14-tag-summary.html, editorial:

- 1.1.1, bullet 1: deleted "i.e., " to end of bullet.
- 1.1.2, para 3: s/document involve human activity/document that involve human activity/
- 1.1.2, para 3: Added ref to voicexml2
----------------------------
revision 1.555
date: 2004/06/03 22:08:46; author: ijacobs; state: Exp; lines: +1 -1
editorial:
s/periodically-updated/periodically updated/
----------------------------
revision 1.554
date: 2004/06/03 22:07:59; author: ijacobs; state: Exp; lines: +32 -25
Per http://www.w3.org/2004/05/14-tag-summary.html, in 1.2.1:

- Changed "independent" back to "orthogonal" (globally)
- Deleted "loosely coupled"
- Expanded this paragraph after the first bulleted list:

When two specifications are orthogonal, one may change one without
requiring changes to the other, even if one has dependencies on the
other. For example, although the HTTP specification depends on the URI
specification, the two may evolve independently. This orthogonality
increases the flexibility and robustness of the Web. For example, one
may refer by URI to an image without knowing anything about the format
chosen to represent the image. This has facilitated the introduction
of image formats such as PNG and SVG without disrupting existing
references to image resources.
----------------------------
revision 1.553
date: 2004/06/03 21:28:12; author: ijacobs; state: Exp; lines: +8 -2

Issue http://www.w3.org/2001/tag/2003/lc1209/issues.html#dhm4

Per http://www.w3.org/2004/05/14-tag-summary.html,

In section 1.2.4, modified first paragraph to talk more about
large-scale protocols v. traditional software APIs.
----------------------------
revision 1.552
date: 2004/06/03 21:13:49; author: ijacobs; state: Exp; lines: +19 -12

Issue http://www.w3.org/2001/tag/2003/lc1209/issues.html#dhm3

Per http://www.w3.org/2004/05/14-tag-summary.html,

In section 1.2.2,

* Extended language: A+B
* Extension: B
----------------------------
revision 1.551
date: 2004/06/03 20:37:54; author: ijacobs; state: Exp; lines: +18 -6
Per http://www.w3.org/2004/05/14-tag-summary.html,

2.1.1: Expanded example to show N resources: one language-independent
and N-1 language-specific.
----------------------------
revision 1.550
date: 2004/06/03 20:18:10; author: ijacobs; state: Exp; lines: +0 -3
Per http://www.w3.org/2004/05/14-tag-summary.html,

1.1.3: Deleted

'This categorization is derived from Roy Fielding's work on
"Representational State Transfer" [REST].'
Changes in 10
May 2004 Editor's Draft
Changes between
7 May 2004 Editor's Draft
and the
10 May 2004 Editor's Draft
diff since 7
May
diff
since 9 Dec 2003
).
1.2.3: In principle, changed "recover" to
"agent recovery".
3.6: In story, changed "unreliable" to "unpredictable".
4.5.4 (and elsewhere): "Namespace document" to "Namespace representation"
Changes in 7
May 2004 Editor's Draft
Changes between
9 Dec 2003 Last Call
Working Draft
and the
7 May 2004 Editor's Draft
diff
).
----------------------------
revision 1.547
date: 2004/05/10 21:32:07; author: ijacobs; state: Exp; lines: +16 -16
Per 9 Feb 2004 TAG teleconf:

s/namespace document/namespace representation/

----------------------------
revision 1.546
date: 2004/05/10 21:25:10; author: ijacobs; state: Exp; lines: +1 -1
Per TAG decision,

s/unreliable/unpredictable

----------------------------
revision 1.531
date: 2004/05/07 23:22:42; author: ijacobs; state: Exp; lines: +4 -1

Per 3 May meeting, added :

Note also that since dereferencing a URI (e.g., using HTTP) does not
involve sending a fragment identifier to a server or other agent,
certain access methods (e.g., HTTP PUT, POST, and DELETE) cannot
be used to interact with secondary resources.

----------------------------
revision 1.530
date: 2004/05/07 23:12:06; author: ijacobs; state: Exp; lines: +2 -7

Per 26 April teleconf, deleted:
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.).

----------------------------
revision 1.528
date: 2004/05/07 23:01:11; author: ijacobs; state: Exp; lines: +51 -50
moved a section around to try to tell a story of disambiguation

----------------------------
revision 1.507
date: 2004/05/07 20:22:52; author: ijacobs; state: Exp; lines: +13 -8

Maybe also

----------------------------
revision 1.506
date: 2004/05/07 20:10:03; author: ijacobs; state: Exp; lines: +0 -4

Deleted:

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

Added text from RFC2396 per

----------------------------
revision 1.505
date: 2004/05/07 20:08:52; author: ijacobs; state: Exp; lines: +2 -1

Added "necessarily" per

----------------------------
revision 1.504
date: 2004/05/07 19:24:08; author: ijacobs; state: Exp; lines: +11 -5
Editorial clarification for

----------------------------
revision 1.503
date: 2004/05/07 19:18:13; author: ijacobs; state: Exp; lines: +22 -19
Editorial changes based on

NOT treated:

(a) Illustration

The shadows in this graphic convey no information; they are (in the
sense defined by Edward Tufte) chartjunk. Please remove them!

----------------------------
revision 1.502
date: 2004/05/07 18:59:13; author: ijacobs; state: Exp; lines: +9 -8
Editorial changes based on

However, did NOT address these:

[Section 1]
The initial part of section 1 is good, but section 1.1 is very jarring
following it. It doesn't flow well at all.

[3.5.1] We are surprised to not see a best practice recommendation here.

[4.5.3] (And elsewhere)
If namespace prefixes are used, there should be a table indicating their
bindings to URIs.

[4.5.6] and [4.5.8] highlight a lot of problems, but make no recommendations
about what to do about them.

----------------------------
revision 1.501
date: 2004/05/07 18:51:38; author: ijacobs; state: Exp; lines: +6 -7

Adopted proposed text:

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

----------------------------
revision 1.500
date: 2004/05/07 18:50:12; author: ijacobs; state: Exp; lines: +3 -2

Adopted proposal:

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

----------------------------
revision 1.499
date: 2004/05/07 18:48:23; author: ijacobs; state: Exp; lines: +1 -2

s/ that can be understood in any context//

Per http://www.w3.org/2004/03/22-tag-summary.html#schema17

----------------------------
revision 1.498
date: 2004/05/07 18:46:24; author: ijacobs; state: Exp; lines: +1 -1

s/JPEG/SVG

[My understanding is: no binary in XML. The JPEG could
be encoded (base64), but happy to put svg instead]

----------------------------
revision 1.497
date: 2004/05/07 18:39:18; author: ijacobs; state: Exp; lines: +38 -17

Added some text from RFC2396 bis per 3 May teleconf. The new
text does NOT say "don't use content negotiation".

----------------------------
revision 1.496
date: 2004/05/07 18:22:58; author: ijacobs; state: Exp; lines: +23 -23
Editorial changes based on

----------------------------
revision 1.495
date: 2004/05/07 18:15:56; author: ijacobs; state: Exp; lines: +4 -5

- Removed legal case as example.
- changed "application context may required" to "favor"

----------------------------
revision 1.494
date: 2004/05/07 18:12:05; author: ijacobs; state: Exp; lines: +1 -1
This text satisfies

----------------------------
revision 1.493
date: 2004/05/07 18:09:01; author: ijacobs; state: Exp; lines: +6 -0
added good practice for URI owners in response to:

----------------------------
revision 1.492
date: 2004/05/07 18:01:24; author: ijacobs; state: Exp; lines: +3 -6

Edited this sentence:

Formats that allow content authors to use URIs instead of local
identifiers foster the "network effect": the value of these formats
grows with the size of the deployed Web.

----------------------------
revision 1.491
date: 2004/05/07 17:54:02; author: ijacobs; state: Exp; lines: +1 -1
I think edited text in 3.4 might address

----------------------------
revision 1.490
date: 2004/05/07 17:52:02; author: ijacobs; state: Exp; lines: +1 -1
Attempt to soften claim about cost of overloading by adding "often"

----------------------------
revision 1.489
date: 2004/05/07 17:50:19; author: ijacobs; state: Exp; lines: +12 -4

No longer talks about silent recovery, but rather recovery
without user consent.

Some text taken from finding:

"Consent does not necessarily imply that the receiving agent must
interrupt the user and require selection of one option or another. The
user may indicate through pre-selected configuration options, modes,
or selectable user interface toggles, with appropriate reporting to
the user when the agent detects an error."

This GPN also updated:

Authoritative metadata: Agents MUST NOT ignore authoritative metadata
unless the user given consent to this behavior.

----------------------------
revision 1.488
date: 2004/05/04 23:41:45; author: ijacobs; state: Exp; lines: +4 -2

Added "or transformed dynamically
to the hardware or software capabilities of the recipient" to
section 3.4

----------------------------
revision 1.487
date: 2004/05/04 23:33:46; author: ijacobs; state: Exp; lines: +14 -0
NEW: Added a paragraph to scope of document on voice browsing and
other interaction contexts.

----------------------------
revision 1.486
date: 2004/05/04 22:49:27; author: ijacobs; state: Exp; lines: +1 -1
Based on comment from Voice WG [1], changed:

"It is a breakdown of the Web architecture if agents cannot use URIs
to reconstruct a "paper trail" of transactions"

to

"It is a breakdown of the Web architecture if agents cannot use URIs
to reconstruct a "paper trail" of transaction results"

[1] http://www.w3.org/2004/03/02-tag-summary.html#voice-liaison
(see discussion of 3.4.2)

----------------------------
revision 1.485
date: 2004/05/04 22:07:27; author: ijacobs; state: Exp; lines: +2 -1
added link to summary

----------------------------
revision 1.480
date: 2004/05/03 15:57:34; author: ijacobs; state: Exp; lines: +30 -27
Per Martin Duerst Comment:

Now only using principle, constraint, good practice (in that order).
Also highlighted in abstract

----------------------------
revision 1.479
date: 2004/05/03 15:46:57; author: ijacobs; state: Exp; lines: +5 -5

Changed indicated titles of GPNs

----------------------------
revision 1.478
date: 2004/04/28 20:31:40; author: ijacobs; state: Exp; lines: +26 -25

- Moved story from beginning of 3.5 to a few paragraphs in.
- Moved one sentence from 3.5 story to 3.5.1 story.

----------------------------
revision 1.477
date: 2004/04/28 20:24:43; author: ijacobs; state: Exp; lines: +18 -15

Did the following editorial (or they were subsumed):

1 under first story in point 2, application/xml+xhtml should be
application/xhtml+xml

1.2, "principles apply *to* across all three bases" - drop the "to"

1.2.1 2nd para: "The fact, for example, that *the* an image..." - drop
the "the"

2.3.1 last sentence misses a 'when': "URI ambiguity arises *when* a URI
is used to identify two..."

3.6.1 should point to 4.5.4 as a good example

3.6.2 second bullet should probably provide a better example, mentioning
the intended semantics of the resource

4 second para - something missing where the X is in "Below we describe
some characteristics of a data format X make it easier to integrate into
the Web architecture."

4.3 remove the 'the': "Experience shows that *the* allowing authors to
separate content,..."

4.3 last sentence missing '-ity': "this follows from the principle of
orthogonal*ity* of specifications".

4.5.3 para below story: "(for example, suppose that the "p" element is
defined in two or more XML formats)" - I suggest that a more concrete
example be added, like mentioning two different meanings possible for
the element "p".

4.5.3 "The type attribute from W3C XML Schema..." should be
distinguished from the type attribute on element declarations; the
customary reference is xsi:type. The whole paragraph doesn't mention
"instance" and says incorrectly that the type attribute is defined the
W3C XML Schema namespace (there are multiple XML Schema namespaces, see
last para of

5 Secondary resource definition doesn't parse, probably should drop the
second "that".

Did NOT do:

5 A Link does not need to be internal to a representation of any of the
two (or more) resources between which there is a relationship, the
definition might want to mention that.

----------------------------
revision 1.476
date: 2004/04/28 20:02:55; author: ijacobs; state: Exp; lines: +7 -2
Per http://www.w3.org/2001/tag/2003/lc1209/issues.html#kopecky1,
added to end of 3.6.1:

"For example, the owner of an XML Namespace should
provide a Namespace Document; below
we discuss useful characteristics of a Namespace Document."

----------------------------
revision 1.475
date: 2004/04/28 19:54:45; author: ijacobs; state: Exp; lines: +7 -6

In GPNs, s/server manager/representation provider/ which I think
is true in its more general form. There is also a connection
between URI owner and "providing a representation" in the
section on authoritative metadata. Not sure yet whether
there needs to be a more formal definition of a representation
provider.

----------------------------
revision 1.474
date: 2004/04/28 19:49:58; author: ijacobs; state: Exp; lines: +34 -33

Once more, in an attempt to reduce the number of subjects
of GPNs:

s/language|format designer/[format] specification/ in the GPNs.

----------------------------
revision 1.473
date: 2004/04/28 19:33:37; author: ijacobs; state: Exp; lines: +42 -35

---
* "authors of a specification" vs "language designer" vs "format
designer"
The distinction between format and language is said to be null in the
document; I believe that usually, format is associated to the syntactic
part of a language (which also includes the semantics); I think that at
least the terms should be used consistently (ie either 'language
designer' or 'format designer') in the conformance requirements, if only
for ease of reading.
Also, the terms "authors of a specifications" seems to be bound to the
same type of subjects, but probably with a wider scope - maybe is there
a way to merge all these terms in one?
--

1) In GPNs, s/Language designer/Specification designer/
2) In document, s/specification author/specification designer/
s/author/content author/
s/developer/software developer/
3) Moved note about format v. language to section on
audience, and introduce phrase "specification designer" as
an encompassing term.

----------------------------
revision 1.472
date: 2004/04/28 18:59:21; author: ijacobs; state: Exp; lines: +3 -3

s/user agent/agent in

"Agents should detect such inconsistencies but should not
resolve them without involving the user."

----------------------------
revision 1.471
date: 2004/04/28 18:58:29; author: ijacobs; state: Exp; lines: +3 -3

Consistent with "Authoritative Metadata" finding and
this reviewer's comment:

Changed "User agents MUST NOT silently ignore authoritative
metadata. "
to

"Agents MUST NOT silently ignore authoritative metadata. "

----------------------------
revision 1.470
date: 2004/04/28 18:56:16; author: ijacobs; state: Exp; lines: +6 -6
s/uri publisher/uri owner per

This is also consistent with eliminating "resource owner",
also suggested by the reviewer.

----------------------------
revision 1.469
date: 2004/04/28 18:15:04; author: ijacobs; state: Exp; lines: +11 -10

Agreed with reviewer based on "Authoritative Metadata" Finding.
Removed "server" from GPN.

Also tweaked some text regarding "authority responsible for
domain X":

In this document, the phrase "authority responsible for domain X"
indicates that the same entity owns those URIs where the authority
component is domain X.

----------------------------
revision 1.468
date: 2004/04/28 17:19:41; author: ijacobs; state: Exp; lines: +6 -5
Editorial changes to text on Unicode.

----------------------------
revision 1.467
date: 2004/04/27 23:07:02; author: ijacobs; state: Exp; lines: +3 -3
Did not implement the following suggestions from sandro hawke:

===========================================
== Comment 2, 1. Introduction:

The server responds with a representation that includes XHTML
data and the Internet Media Type "application/xml+xhtml".

In the graphic, you show the media type as text/html, which is
probably the better choice for simplicity's sake.

Rationale: Adjusted image to application/xhtml+xml.

===========================================
== Comment 3, 1.1.3 Principles, Constraints, and Good Practice

This categorization is derived from Roy Fielding's work on
"Representational State Transfer" [REST]. 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.

The first sentence is fine, the second reads rather like a paid
product placement. Is Fielding's thesis that much better than every
other work ever written on distributed systems design that it merits
strong recommendation in the section introducing labeling terms? If
you want to save this text, put it in a Recommended Reading section.

===========================================
== Comment 7, 1.2.4. Protocol-based Interoperability

Did NOT add a GPN.

=======================

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.

=======================

----------------------------
revision 1.466
date: 2004/04/27 23:06:03; author: ijacobs; state: Exp; lines: +6 -3

Tried to clarify meaning of "safe" by adding note:

"Note: In this context, the word "unsafe" does not mean
"dangerous"; the term "safe" is used in section 9.1.1 of
[RFC2616] and "unsafe" is the natural opposite."

----------------------------
revision 1.465
date: 2004/04/27 22:59:59; author: ijacobs; state: Exp; lines: +4 -4
Followed

In 3.2, s/electronic data/data

----------------------------
revision 1.464
date: 2004/04/27 22:59:17; author: ijacobs; state: Exp; lines: +5 -5
Followed suggestion of

s/representation of the state of a resource/representation of a
resource/

However, left "resource state" elsewhere.

----------------------------
revision 1.462
date: 2004/04/27 22:43:01; author: ijacobs; state: Exp; lines: +17 -6
markup fixes, added more example of sameAs per

----------------------------
revision 1.461
date: 2004/04/27 22:16:37; author: ijacobs; state: Exp; lines: +36 -40
Proposed fix to

in previous edits.

In this draft, adopted SH proposal to s/URI ambiguity/URI overloading/

As a result I *also* deleted the paragraph on natural language
ambiguity; this seems less and less relevant. I substituted
a paragraph at the end of the section on authoritative metadata:

"Note that the choice and expressive power of a format can affect
how precisely a representation provider communicates resource state.
The use of natural language to communicate resource state may lead to
ambiguity about what the associated resource is. This ambiguity can in
turn lead to URI overloading."

----------------------------
revision 1.460
date: 2004/04/27 21:56:05; author: ijacobs; state: Exp; lines: +10 -11

===========================================
== Comment 9, 2.2. URI Ownership

... the "uuid" scheme ...
and
... the "md5" scheme ...

but you don't give references. 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.

For uuid you could use urn:nid-5, but that's technically not a
"URI scheme":

Maybe you can says "such as a possible 'UUID' scheme", etc, or you
could use WebDAV's unique-lock-token scheme.

Instead:

Merged "Random number" and "Checksums" list items into one
list item:

"Large numbers. The generation of a fairly large random
number or a checksum
reduces the risk of ambiguity to a calculated small risk.
A draft "uuid" scheme adopted this approach; one could also
imagine a scheme based on md5 checksums."

----------------------------
revision 1.458
date: 2004/04/27 21:47:31; author: ijacobs; state: Exp; lines: +5 -5
Agreed with and implemented

----------------------------
revision 1.457
date: 2004/04/27 21:38:14; author: ijacobs; state: Exp; lines: +12 -7
As suggested by SH, added forward link. However, did not
add a GPN. Added "View source effect" to the glossary.

===========================================
== Comment 7, 1.2.4. Protocol-based Interoperability

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.

This seems out of place. I get the point, but it's never summed up.
And I don't see how it belongs in 1.2 General Architecture Principles.

I think you mean:

Good practice: design protocols and data formats which
people can view and reproduce with a minimum of special tools and
effort.

[ Ahhh, this is finally covered in Section 4.1; maybe a forward link? ]

and maybe:

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.
----------------------------
revision 1.456
date: 2004/04/27 21:15:18; author: ijacobs; state: Exp; lines: +7 -7
Based on comment from SH:

QUOTE
===========================================
== Comment 6, 1.2.2. Extensibility:

The following applies to languages, in particular the
specifications of data formats, of message formats, and
URIs. Note: This document does not distinguish in any formal way
the terms "format" and "language." Context has determined which
term is used.

I can't really parse the first sentence. Maybe you mean something like:

The data formats and (more generally) formal languages used
in the bodies of messages and even in the text of URIs can be
defined to have certain properties to promote evolution and
interoperation.
/QUOTE

Changed to:

"Below we discuss the property of "extensibility," exhibited by URIs
and some data and message formats, which promotes technology evolution and
interoperability.
Note:
This document does not
distinguish in any formal way the terms "format" and "language."
Context determines which term is used."

----------------------------
revision 1.455
date: 2004/04/27 21:06:03; author: ijacobs; state: Exp; lines: +3 -3
Accepted proposal from SH:

===========================================
== Comment 4, 1.2.1. Orthogonal Specifications:

... agents can interact with any identifier ...

That's ambiguous. Replace "with" with "using" and I think you're
okay. Otherwise it sounds rather like the identifier is one of the
parties doing something in an interaction.

----------------------------
revision 1.454
date: 2004/04/27 21:04:26; author: ijacobs; state: Exp; lines: +5 -5
Accepted proposal from SH:

===========================================
== Comment 1, 1. Introduction:

Identification. Each resource is identified by a URI. In this
travel scenario, the resource is about the weather in Oaxaca and
the URI... ^^^^^

This was jarring to read. The text up to that point is simple and
direct, but suddenly here there's handwaving with "about." What *is*
the resource identified by that URI? Fortunately, in the picture you
answer this question.

Suggested text:

Each resource is identified by a URI. In this travel scenario, the
resource is a periodically-updated report on the weather in Oaxaca,
and the URI ...

----------------------------
revision 1.453
date: 2004/04/27 20:44:32; author: ijacobs; state: Exp; lines: +24 -21
More clean-up of resource owner v. URI owner.
I hope this resolves

----------------------------
revision 1.452
date: 2004/04/27 20:35:03; author: ijacobs; state: Exp; lines: +3 -3
Previous changes take into account these issues:

NOT DONE from Patrick's comments:

------------

Section 3.2, para 1, last sentence:

Consider changing to "A message may even include metadata about the
message itself (for message-integrity checks, for instance).

Rationale: This is about the message metadata, not the message,
I believe.

------------

Section 3.3.1, last para, last sentence:

This sentence seems misleading, as if one can infer something
about the nature of a secondary resource by interpreting a
URI reference with fragement identifier.

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

This last sentence could either be removed or clarified/reworked.

-------------

These issues:
----------------------------
revision 1.451
date: 2004/04/27 20:24:43; author: ijacobs; state: Exp; lines: +3 -3
Per stickler comments:

s/cell phone/mobile phone

----------------------------
revision 1.450
date: 2004/04/27 20:21:13; author: ijacobs; state: Exp; lines: +13 -13
Deleted "Resource owner" from the document, replacing it with
URI owner.

----------------------------
revision 1.449
date: 2004/04/27 20:11:32; author: ijacobs; state: Exp; lines: +13 -7
Clarified per suggestion of stickler1

Section 3.6, para 1:

- Per suggestion from PS, added two more examples of
unreliability.
- Continue to move away from "resource owner" (since nobody
owns the weather in Oaxaca) to "URI owner".

----------------------------
revision 1.448
date: 2004/04/27 20:05:51; author: ijacobs; state: Exp; lines: +9 -7
Clarified per suggestion of stickler1

Story in 3.5.1 on unsafe interactions and accountability.

----------------------------
revision 1.447
date: 2004/04/27 19:34:16; author: ijacobs; state: Exp; lines: +24 -17
Per suggestion of stickler1

"Section 3.4, para 2:

The text of this paragraph is a bit too strong regarding URI owner's
rights.

The owner of a URI has the right to decide which representations
of the denoted resource are accessible via that URI -- but in fact
anyone has the license to create a representation of that resource,
and indirectly associate that representation via another URI
that is declared (e.g. using own:sameAs) as semantically equivalent.
I.e. the rights of the owner of a URI are limited to the access of
representations via that particular URI, not (necessarily) to total
control of the resource denoted as well as any and all representations
of that resource (accessible via other URIs)."

Did two things:

1) Added this to the section on future directions and URIs:

"One consequence of this direction is that URIs syntactically
different can be used to identify the same resource. This means that
multiple parties may create representations of the (same) resource,
all available for retrieval using multiple URIs. The URI owner's
rights (e.g., to provide authoritative representation metadata) extend
only to the representations served for requests given that URI."

2) Changed:

In our travel scenario, the authority
responsible for "weather.example.com" has license to create
representations of this resource. Which representation(s) Nadia receives
depends on a number of factors, including:

to:

In our travel scenario, the owner
of "http://weather.example.com/oaxaca" provides the
authoritative metadata for representations retrieved for
that URI. Precisely which representation(s) Nadia receives
depends on a number of factors, including:

----------------------------
revision 1.446
date: 2004/04/27 19:15:55; author: ijacobs; state: Exp; lines: +7 -5
stickler1

Section 3.4, para 1, last sentence:

The phrase "authoritative interpretation of representations of
the resource" is a bit unclear. The owner of the URI can specify
the denotation of the URI and what representations of that
resource are accessible, but is it not the case that the MIME
type specifications define the interpretation of any given
representation -- insofar as the web architecture is concerned?

I.e., for a given representation, it is the MIME type specification
that defines the interpretation of that representation, not the
owner of the URI denoting the represented resource. ???

FIXED (though might require additional editing) according
to the "Authoritative Metadata" finding.

----------------------------
revision 1.445
date: 2004/04/27 19:09:00; author: ijacobs; state: Exp; lines: +9 -13
Per suggestion of stickler1

Removed first part of para after story, since it said almost
the same thing as following paragraph and was less clear.

----------------------------
revision 1.444
date: 2004/04/27 19:00:56; author: ijacobs; state: Exp; lines: +3 -3
tweak in section 3.2, para 1: added "itself"

----------------------------
revision 1.443
date: 2004/04/27 18:59:33; author: ijacobs; state: Exp; lines: +12 -6
Per suggestion of stickler1

Adopted suggested replacement sentence in 3.1:

Access may take many forms, including
retrieving a representation of the state of the resource (for instance,
by using HTTP GET or HEAD), adding or modifying a representation of
the state of the resource (for instance, by using HTTP POST or PUT,
which in some cases may change the actual state of the resource if
the submitted representations are interpreted as instructions to that
affect), and deleting some or all representations of the state of the
resource (for instance, by using HTTP DELETE, which in some cases may
result in the deletion of the resource itself)."

----------------------------
revision 1.442
date: 2004/04/27 18:57:46; author: ijacobs; state: Exp; lines: +25 -11
Per suggestion of stickler1

Added example in 2.3 on URI ambiguity. Also moved some
content around to try to better explain what it means.

----------------------------
revision 1.441
date: 2004/04/23 19:45:48; author: ijacobs; state: Exp; lines: +4 -4
Also tried to make clearer that "URI ambiguity" means that
the URI is used to refer to more than one resource in a context
of Web protocols and formats.

----------------------------
revision 1.440
date: 2004/04/23 19:44:35; author: ijacobs; state: Exp; lines: +11 -11
per http://www.w3.org/2001/tag/2003/lc1209/issues.html#stickler1

- s/Web resource/resource globally to avoid confusion.
- In 2.3, changed last sentence to:

"URI ambiguity arises when a URI is used to identify two different
resources outside the context of Web protocols and formats."

----------------------------
revision 1.439
date: 2004/04/23 19:35:32; author: ijacobs; state: Exp; lines: +7 -4
per http://www.w3.org/2001/tag/2003/lc1209/issues.html#stickler1

Added example in 2.1:

"By following the "http" URI specification, agents are licensed to
conclude that "http://Weather.Example.Com/Oaxaca" and
"http://weather.example.com/Oaxaca" identify the same resource."

----------------------------
revision 1.438
date: 2004/04/23 16:33:45; author: ijacobs; state: Exp; lines: +82 -65
Editorial changes based on

In particular, reorganized 2.1 to read more clearly, and
made second half a new subsection.

----------------------------
revision 1.437
date: 2004/04/23 15:32:22; author: ijacobs; state: Exp; lines: +9 -5
Added sentence to GPN in 4.5.4 per

"When a namespace representation is provided by
the authority responsible for the namespace, that material
is authoritative."

Also changed "Resource owner" to "Authority responsible for
[an XML Namespace Name]"

----------------------------
revision 1.436
date: 2004/04/21 23:54:53; author: ijacobs; state: Exp; lines: +29 -21

Added forward link to section on representation management (3.6.3).
Also reworked the text to state more clearly:

URI owners get to serve authoritative metadata.

----------------------------
revision 1.435
date: 2004/04/21 23:24:17; author: ijacobs; state: Exp; lines: +4 -4
Issue http://www.w3.org/2001/tag/2003/lc1209/issues.html#ducharme1
Source

Minor editorial fixes:

1.2.2 "Context has determined which term" should read "Context determines
which term" for agreement of tense with sentence that precedes this ones.

1.2.3 "error condition so that a an agent" "so that an agent"

----------------------------
revision 1.434
date: 2004/04/21 23:22:53; author: ijacobs; state: Exp; lines: +8 -4
Issue http://www.w3.org/2001/tag/2003/lc1209/issues.html#ducharme1
Source

Improved glossary entry for "secondary resource"

----------------------------
revision 1.433
date: 2004/04/21 23:18:35; author: ijacobs; state: Exp; lines: +9 -7
Issue http://www.w3.org/2001/tag/2003/lc1209/issues.html#ducharme1
Source

4.5.6, number 3: changed
"might reveal the attributes of type ID" to
"might reveal the attributes declared to be of type ID".

Made some other minor tweaks as well.

----------------------------
revision 1.432
date: 2004/04/21 23:15:42; author: ijacobs; state: Exp; lines: +9 -5
Issue http://www.w3.org/2001/tag/2003/lc1209/issues.html#ducharme1
Source

3.4.1: Added examples to both bullets.

----------------------------
revision 1.431
date: 2004/04/21 23:01:45; author: ijacobs; state: Exp; lines: +13 -14
Issue http://www.w3.org/2001/tag/2003/lc1209/issues.html#ducharme1
Source

Globally changed "orthogonal" to "independent"

----------------------------
revision 1.430
date: 2004/04/21 22:59:47; author: ijacobs; state: Exp; lines: +7 -5
Issue http://www.w3.org/2001/tag/2003/lc1209/issues.html#ducharme1
Source

1.1.3:

s/

/
also made the explanation a little more self-contained.

----------------------------
revision 1.429
date: 2004/04/21 22:57:02; author: ijacobs; state: Exp; lines: +3 -3
Issue http://www.w3.org/2001/tag/2003/lc1209/issues.html#ducharme1
Source

1.1 s/at least//

----------------------------
revision 1.428
date: 2004/04/21 21:56:35; author: ijacobs; state: Exp; lines: +4 -3
added clarification of what the "authority component" part
of an http URI is.
Cf:

----------------------------
revision 1.427
date: 2004/04/21 21:49:44; author: ijacobs; state: Exp; lines: +3 -3
bug fix in media type of intro story

----------------------------
revision 1.426
date: 2004/04/21 20:09:10; author: ijacobs; state: Exp; lines: +4 -4

Comment: "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."

Solution: Changed title to "URI nonuniqueness"

----------------------------
revision 1.424
date: 2004/03/31 22:56:51; author: ijacobs; state: Exp; lines: +15 -14
Editorial changes based on

- All typos fixed.

IMPLEMENTED:

* Sect 5 - Term Index. Maybe missing some terms? Would be useful to see
'Web' (and 'WWW', 'World Wide Web'), 'URI' (as a 'see Unifo...'
cross-reference), 'Data Format', 'Media Type' (maybe).

* Sect 2.4.1, 2nd para, 3rd bullet, 'One should not expect...' - suggest
change from 'will do anything useful with URIs of this scheme' to something
like 'will do anything with URIs of this scheme beyond comparison' or some
other wording.

* Sect 4.1. Suggest to interchange 1st and 2nd paras to reflect order in
section title.

DID NOT IMPLEMENT:

>* Sect 4 is entitled 'Data Formats', and Sect 1, 3rd bullet has 'Formats'.
>Would suggest that both should be changed to 'Representation' in keeping
>with the 3 bases articulated in the Abstract (identification, interaction,
>representation). This shift in gears from representation to data formats is
>potentially confusing. Maybe within the section one could talk of data
>formats (as a more concrete realization of the abstraction
>'representation'), but I think the section (and bullet) are better labeled
>at the more generic/abstract level.

We used to have that and then chose the current organization
instead.

>* Almost all the Story examples seem to make use of HTTP URIs. Any chance of
>sneaking in some other URI schemes just here and there just to reinforce
>that the fact that this is a democrarcy not a monarchy? Perhaps even just a
>mailto, or urn, or something more exotic?

We have examples of other schemes. No need to use exotic schemes
if not motivated by story.

>* Sect 6 - References. Still minded to have a division between normative and
>informative refs. Otherwise seems rather haphazard like the Web itself. Cf.
>the [IETFXML] entry: 'This IETF Internet Draft is available at .... If this
>document is no longer available, refer to...' And BTW, my understanding is
>that I-Ds should ony be referenced as a work in progress. Same with [IRI]
>entry below.

TAG did not feel the need to have normative refs.

>* Sect 2.4, 3rd para, 1st sentence, 'While the Web architecture...' - change
>'is costly' to 'can be costly'?

Not sure about this one.

>* Sect 2.4, 3rd para, 3rd sentence, 'Introducing a new URI scheme...' -
>change 'requires' to 'may require'?

Not sure about this one.

>(There is the problem here that unregistered scheme URIs may not be
>authoritatively compared. OTOH if we have a registered scheme URI and an
>unregistered scheme URI *using the same scheme* - can we authoritatively
>compare them? Anyway, the point I am trying to bring out in this comment is
>that URI identity/comparison is in and of itself a powerful utility, beyond
>dereference.)
>* Sect 2.4, last para, last sentence - 'When an agent does not handle a new
>URI scheme, it cannot retrieve a representation.' This seems prejudicial, as
>if the only intersting operations are retrieval. An agent can already make
>use of the identitiy afforded by a URI and comparison of URIs in
>applications such as merging of RDF graphs or of merging Topic Maps which
>identify resources by means of URIs.

Nonetheless, the statement is true.

>* Sect 3, last para ('Note') before Sect 3.1. I would strongly query the
>sentence '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 ...'. I would
>rather say that a resource is "on the Web" when it is referenced by means of
>a URI. That would seem to me to be a full and sufficient condition. A
>resource referenced by a URI participates within the Web information space
>and assertions can be made about that resource.

The TAG did not agree to that definition.

>* Sect 3.6.2, 1st para. Should clarify here that 'URI persistence' actualy
>refers to persistence of the referenced resource, not to the URI. (That
>point is made in the [Cool] reference entry but should be made here and not
>in the refrence section.)

Having reread the sentence, I don't believe that's necessary. It's
defined clearly.

>* Sect 4.5.5, 1st para, 2nd sentence. 'A qualified name is a pair consisting
>of a URI,..., and a local name...' Surely the qualified name itself consists
>of a 'prefix' which represents the URI (i.e. is a URI placeholder), and a
>local name?

I think that's a qname rather than a qualified name.

----------------------------
revision 1.423
date: 2004/03/31 21:21:55; author: ijacobs; state: Exp; lines: +15 -2
Per comments from Tony Hammond

Added World Wide Web, WWW, Web, and URI to the term index.
Changes in 9
December 2003 Last Call Working Draft
Changes between
5 Dec 2003 Editor's Draft
and the
9 Dec 2003 Last Call
Working Draft
3.3.1 Editorial changes
Changes in 5
December 2003 Editor's Draft
Changes between
3 Dec 2003 Editor's Draft
and the
5 Dec 2003 Editor's Draft
diff
).
1.2.2 Extensibility:
Per
4 Dec 2003 TAG teleconf
Revised text with NW and TBL.
2.4 URI Schemes:
Per
4 Dec 2003 TAG teleconf
removed "https" example. Also, per NW suggestion, replaced urn
example.
2.6 Fragment identifiers: Removed "formal description". Added
new para instead to 3.3.1
Incorporated some comments from Stuart Williams' 4 December
review.
1 Introduction: Second bullet, d/about Web resource/
1 Introduction: Second bullet, a/the exchange of/
1.1.2 Scope: Minor editorial
2. Identification: Added cross ref to section about URIs
in other roles.
2.1 URI comparisons: Made parenthetical into its own
sentence.
2.2 URI Ownership: s/two/different/ in first sentence.
2.2 URI Ownership: d/specifications, as expressed through
protocol messages/
4.5.5: In GPN, s/indistinguishable./indistinguishable from URIs.
Changes in 3
December 2003 Editor's Draft
Changes between
28 Nov
2003 Editor's Draft
and the
3 Dec 2003 Editor's Draft
diff
).
Per
15
Nov ftf meeting
, removed references to any draft
findings leaving pointers to the issues list instead.
1. Introduction. New illustration.
1.2.1 Orthogonal Specifications: Per
TB
comments
, deleted "Similarly, XML schema is defined as a schema
language where the concept "datatype" is filled by an independent list
of data types. The schema language can be extended by adding new
datatypes."
1.2.1 Orthogonal Specifications: Per
1 Dec
teleconf
added more info to second bullet in 1.2.1 about feature
of HTML not widely deployed in HTTP servers. Also, edited
the third bullet.
1.2.2 Extensibility: Per
TB
comments
, changed title to "Extensibility".
Also, some typo fixes and merged CSS/XSLT/SOAP into one bullet.
1.2.2 Extensibility: Per TBL discussion at
1 Dec
teleconf
, added back information about
interpreting instances of superset in subset language:
"Clearly, creating an extension language is better for
interoperability than creating an incompatible language. In practice,
even greater interoperability is required. Ideally, it should be
possible to interpret many instances of the extension language as
though the were instances of the subset language."
1.2.4. Protocol-based Interoperability:
Per
1 Dec
teleconf
s/messages exchanged/technology shared.
Changed first sentence of first para to:
"The Web follows Internet tradition in that its important interfaces
are defined in terms of protocols, by specifying the syntax,
semantics, and sequence of the messages interchanged."
Edited next sentence to be:
" The technology
shared among Web agents lasts longer than the agents themselves."
Deleted third para on sax
2. Identification:
Per
1 Dec
teleconf
, deleted following sentence from first para of 2
"This shared vocabulary has a
tangible value: it reduces the cost of communication."
2. Identification: Moved some paragraphs around to try to
make the text read better. Moved constraint on URI uniqueness
to 2.1, where it was already discussed.
2.2. URI Ownership:
Per
1 Dec
teleconf
, deleted from 2.2
"Of particular importance are those messages that express a
relationship between a URI and a representation of the resource it
identifies. "
2.3.1. URIs in other Roles: Rewritten, based on IJ proposal
and discussion on list.
2.4. URI Schemes: Per Tim Bray suggestion, clarifications
to last para. Also, deleted last sentence of first paragraph
since this topic is covered later on in the section on
accessing resources.
2.4. URI Schemes: Edits for clarification to first bullet
of second list: "It violates the principle of
orthogonal specifications since the URI scheme specification
makes requirements about the dereference protocol." Also,
some edits to last para of this section based on TB text.
2.7.2: Per TB suggestion, s/Determination/Assertion/ in
title. Also, added back
functionalProperty
per
TBL suggestion.
3.1. Using a URI to Access a Resource:
per TB comment and CL proposal, clarified href/XLink stuff.
3.2. Messages and Representations:
Per
1 Dec
teleconf
, adopted "A message may include representation data as well as
metadata about the resource, the representation, and the message."
Also added to that sentence examples that appeared below.
Then Deleted para after ordered list as a result.
3.4.1. Inconsistencies between Metadata and Representation Data:
Per
1 Dec
teleconf
, deleted good practice note at end of section. Also,
rewrote first sentence of preceding para to be:
"Furthermore, server managers can help reduce the risk of error through careful assignment of representation metadata (especially that which applies across representations)."
3.5. Safe Interactions:
Per
1 Dec
teleconf
, deleted "built with Xforms"
3.6.2. URI Persistence: Text inadvertently cut while
editing was restored in the first sentence of the first para.
4.2.2. Versioning and XML Namespace Policy:
Per
1 Dec
teleconf
, s/markup from an unrecognized namespace/unrecognized
markup/. Also, per TB suggestion, made this a new section (taken from
material of previous section).
4.5.2. Links in XML:
Per
1 Dec
teleconf
editorial change to avoid "consider" twice
(though "using" appears twice)
4.5.5. QNames in XML:
Per
1 Dec
teleconf
, rewritten after discussions with Stuart.
Old 4.6: Deleted per TB suggestion. Moved
reference to issue 29
to section in 1.2 on extensibility (where "profile" is used).
References: Reordered some references.
Changes in 28
November 2003 Editor's Draft
Changes between
11 Nov
2003 Editor's Draft
and the
28 Nov
2003 Editor's Draft
diff
).
Most of these changes were the result of the TAG's ftf meeting
in Japan (
minutes
). A fair
number of editorial changes are not listed here, based
on a previous IJ review,
TB
review
TBL
review
, and
SW
review
General:
Deleted editor's notes (except in abstract)
Verified that stories use XHTML consistently (not mixing
HTML and XHTML).
Good practice notes are now all noun phrases.
Deleted from around URIs (leaving quotes)
Define "agent" as people + software; verified usage.
Changed "hyperlink" to "hypertext link".
s/very//g
s/format/data format/g
s/format specification author/language designer/g
In sections on future work, deleted
"The TAG makes no commitment at this time to pursuing these issues."
Status section: Prepping for last call. Added info about
relation of arch doc to findings. Added info about [URI].
1. Introduction. Revised diagram (part about representation).
Deleted ed note from just before 1.1.
1.2.1 Orthogonal specifications: Heavily edited; many edits
based on
proposal
from DC
. Also added synonyms "loosely coupled" and "independent".
In first bullet, added TBL's comment from 15 Nov ftf meeting that URI query
design in case of HTML forms impinges on server design. In second
bullet, added comment about user agent interpretation of META/refresh.
1.2.2. Extensibility of Languages: New section based on
language
from TBL and DO
1.2.3. Error Handling: Deleted second good practice note -
"Specification authors SHOULD specify agent behavior in the face of
error conditions"
1.2.4. Protocol-based Interoperability: New title, other edits
based on ftf discussion, added reference to [SAX].
2. Identification: s/linked-to/refer to.
Edits to principle "URI assignment". Added parenthetical comment
about [URI] being revised.
Added
TBL para
just before principle "URI Assignment".
2.2. URI Ownership. New section based on
text
from TBL
and
text
from DC
. Note in particular mention of
reliance on DNS.
2.3. URI Ambiguity. Revised per
proposed
text from TB
. Put back link to Gutenberg project. New
subsection 2.3.1
2.4. URI Schemes:
Moved info about IANA from 2 to here.
Revised text on cost of introducing a new URI scheme.
Added https as an example.
State more clearly that when you introduce a new format,
use IMT not URI scheme
Added para about "can't follow your nose"
Deleted editor's note.
Added ref to RFC2818
2.4.1. URI Scheme Registration. Added example of ftp in Note.
[Old] 2.6.3. Work on Dynamic Authority Delegation. Deleted
[Old] 2.6.4. Non-hierarchical Administration. Deleted
2.7.2. Expression that Two URIs Identify the Same Resource
(formerly 2.6.2). s/equivalentTo/sameAs and deleted functionalProperty
in section. New title for section.
3. Interaction. Deleted first paragraph. Deleted editor's
note and replaced with dfn of "on the Web".
3.1. Using a URI to Access a Resource:
Updated SVG example based on CL text and ftf discussion. Also,
mention of application context in paragraph before story.
3.2. Messages and Representations. Added "SOAP" to list of
protocols. Modified first para. Edited second bullet; IMT now its own
sentence.
3.3. Internet Media Type: Deleted
"If the agent implements those specifications, it interprets the data
accordingly; error handling is discussed below."
3.3.1. Media Types and Fragment Identifier Semantics: Replaced
"geeky language" with a nadia/dirk story.
Moved text about using a URI without a representation
from earlier section to this section.
3.3.2. Fragment Identifiers and Multiple Representations. Continue
story from 3.3.1. Added cross-ref to section on URI ambiguity.
3.4. Authoritative Representation Metadata:
Made editorial tweak and added cross-ref to charset/XML
example that follows. I changed the principle to good practice. I did not delete
it though I am tempted to since the preceding paragraph
suffices.
3.5 Safe interactions: Added XForms to story.
3.5.1. Unsafe Interactions and Accountability: New subsection
based on discussions about tracking POST interactions.
3.6.3. Linking and Access Control: New title
3.7. Future Directions for Interaction: Added more technologies
and links to relevant resources.
4. Data Formats: Removed old subsection 4.1 including the good
practice notes. Some of the text left at beginning of 4.
Some info about representations moved up to 2.5, xref to 2.5 in
4.
4.1. Binary and Textual Data Formats:
Edits to 2nd and 3rd para as proposed by SW and NW.
Demoted (former) good practice note. Fixed reference to issue 30.
4.2. Versioning and Extensibility:
Clearer that specs need to plan for in advance.
removed sentence on OWL (to be put in finding)
Added text from NW on cost/benefit tradeoff
Split into three subsections for readability and reorged
for better transition.
Text formerly in 4.6.4 (namespaces and versioning) moved to 4.2.1.
Updates to story in 4.2.1 to tie more into extensibility.
4.2.2. Extensibility:
Change to "must understand" description based on
TB comment
New section 4.2.3 based on
TBL text
; taken from old "future
directions" section
4.3. Separation of Content, Presentation, and Interaction:
s/content logic/content
Added xref to DIPRINCIPLES
Added examples of SVG and XSL FO for the rubber hitting the road.
More obvious xref to orthogonality and deriving GPN from principle.
Elaborated on CL's text on delivery context, discussing spectrum
of recombination between client-side and server-side.
4.4. Hypertext:
Retitle 4.5 "Hypertext"
Use TBL's proposed text for 2 that doesn't use the term "link"
Keep definition of "link" in 4.5
Define Link ::= URI Metadata*
Create subsection on uri references; fix text about building links to better text on absolutizing.
d/Hyperlink
In 4.5, first para, include example of absolute URI (with /foo)
d/Last sentence of paragraph after "Web linking" GPN
Lose the active/passive text; see TB text.
New subsection 4.4.1 on URI Refs
4.5.2. Links in XML: Split off from previous section on qnames
and xml. New sentence: "XLink is an appropriate specification for
representing links in hypertext XML applications."
4.5.4. Namespace Documents: s/best data format/no established best practice/
4.5.5. QNames in XML: Uses new
text
from NW
. Added ref to RDF and issue 37.
4.6.1. XML Profiles. Now just includes link to issue 29
[Old] 5. Conformance. Deleted.
Moved 2119 refs to 1.1. Also added to 1.1
rationale why no conformance section.
[New] 5. Term index. Now includes definitions as well as
links back to definition in context.
[Old] 6. Glossary: Deleted. Info about principles, etc. now
in 1.1.3.
[New] 6. References
Renamed "Normative refs" as "Internet Specs" since there is
no conformance provision for this document
Deleted DAML+OIL since OWL there.
Added a number of references...
Most references now stored in refs.xsl; biblio info
extracted automatically from W3C TR page data. However, not
all entries are in alphabetical order yet...
Changes in 11
November 2003 Editor's Draft
Changes between
27 Oct 2003
Editor's Draft
and
11 Nov
2003 Editor's Draft
diff
).
Old 1.2.3 Web as a Distributed System: Deleted after discussion
with Tim Bray. Moved some text to other parts of the document (e.g.,
scope of URIs is global to third para of 2)
New 1.2.3 Syntax and Interoperability: New text based on
text
proposed by Dan Connolly
2 Identification: New Constraint: "The identification mechanism
for the Web is the URI", based on discussions with DC.
2.2 URI ambiguity. New first sentence to give a little more
tie-in to previous statements.
2.3 URI Schemes. Added editor's note about requiring more
justification for media type over scheme.
2.5 Fragment identifiers. Clarified end of paragraph following
bulleted list, on URIs-with-frags-when-no-representation. Added new
paragraph just before 2.6 that refers to abstract component refs finding.
3 Interaction. New opening paragraph for this section.
3.2 Messages and representations. Clearer statement that
representation is data + metadata. HTTP case is special case where
there is also resource metadata. Media is one piece of representation
metadata. Clarify also in last para that POST response does not
carry representation of originally identified resource.
3.6 Representation management. New story added at beginning of
this section.
Old 3.8. Deleted this section
4 Data Formats (formerly "Formats")
4.3 Extensibility and Versioning. New text based on DO/NW
proposal, then IJ proposal, then convergeant proposal
4.5 Links (new title). Introduce notion of base URI. Some
clarifications about resolution of URI ref. New sentence in para
before "Generic URIs" needs review.
4.6.2 Links and Qnames in XML. Formerly section 4.6.2; new
title. All sections on namespaces now adjacent.
4.6.4 XML Namespaces and Versioning. New text based on DO/NW
proposal, then IJ proposal, then convergeant proposal
4.6.7 Media Types for XML. Elevated one statement to good
practice note on character encoding; related to RFC3023
Deleted the definitions of terms backward/forward compatibility
and extensible format specification. Added URI reference and base URI.
Incorporated other
editorial comments from Tim Bray
Changes in 27
October 2003 Editor's Draft
Changes between
1 Oct 2003
Working Draft
and
27 Oct 2003
Editor's Draft
Unless otherwise indicated, the changes in this draft were the
result of discussion at the TAG's
Bristol ftf
meeting
Abstract: Added editor's note.
1. Introduction:
Delete first sentences (about messages) from bullets 2, 3.
in paragraph above numbered items, s/divisions/dimensions/
s/information objects/things of interest/
In bullet three after story, change "A resource communicates
everything about its state through these representations" to "A
resource communicates state information through these
representations"
In section on interactions, only SOME messages carry representations
1.1.2 Scope of this Document:
Added statement
"The findings do not contain good practice notes, principles, etc.
beyond those that appear in the current document."
In third para, reused text that used to be good practice note
on understanding REST.
1.2 General Arch Principles.
New section
This
section is the result of an action to move some generic principles
that affect the three legs of the tripod to a section on general
architectural principles. Some of this text is
new
attempting to regroup things that the TAG has already discussed.
It should be reviewed
1.2.1 Orthogonal specifications. Not only is this
section new, incorporated
text
from Norm
2 Identification
First para edited. First sentence of second para edited.
Deleted "(URI), defined in "Uniform Resource Identifiers (URI):
Generic Syntax"
d/(i.e., name)/
Upgraded statement to a constraint: "Web architecture does not
constrain a Web resource to be identified by a single URI." Text after
edited in light of Bristol discussion. Section on linking moved
to 4.5
Implemented
proposal
from TB to move text from 2.2
2.1 URI Comparisons:
Edits to first paragraph.
Former good practice note split into two in this section, one
for consumers, one for producers.
2.2 URI Ambiguity:
Formerly ambiguity and persistence. Persistence considered
a property of the respresentations, so moved to 3.6
Incorporated
proposed
text from NW
2.3 URI Schemes:
Examples reduced to URIs; no explanation given. Lost historical
discussion. Changed mailto examples per RF suggestions.
Added Editor's note to end of section 2.3
2.4 URI Opacity:
First two paras rewritten with more rationale.
mailto example updated
Moved part about policy to next-to-last sentence in the
section: "In some cases, relevant technical specifications license URI assignment authorities to publish assignment policies."
2.5 Fragment identifiers: Some info moved to 3.3.1 and 3.3.2
3 Interaction. Moved story up front. Message described
as an event, not an octet sequence.
3.1 Using a URI to acccess a resource:
Most of this section used to be in the old 2.5.
Updated label from SVG10 to SVG11.
3.3 Internet Media Type. This is text that used to be
buried at the beginning of 3.
3.3.1 Media types and frag id semantics. This text has been
rewritten to clarify points made by Chris at ftf meeting.
3.3.2. Fragment Identifiers and Multiple Representations:
Fomerly 2.4.2 with clarifications from Bristol
3.5 Safe interactions: Formerly 2.5.2
3.6 Representation Management.
New
container
section. Good practice note edited per Bristol
3.6.1 Representation availability: Formerly part of 2.6. The
distinction between 3.6.1 and 3.6.2 was the result of Bristol
discussion.
3.6.2 URI Persistence: Formerly part of 2.6.
3.6.3 Access control: Formerly 2.7. Story edited
per Bristol.
4 Formats: Moved info about representations to section 3.2.
Section 4 was almost exclusively about data formats. I moved
the representation layer (namely the media type parts) to section 3.
This may have been too strong a move; it may be that "representation"
info belongs right at the beginning of 4. Note at end
of section added about format/vocabulary/language.
4.1. Interoperability and the Use of Standard Format
Specifications:
Deleted ""For example, if a format is required to contain human-readable text
with embedded hyperlinks, it is almost certainly better to use HTML
for this purpose than to invent a new format."
4.2 Binary and textual data formats: Added good practice
note.
4.4. Separation of Presentation, Content, and Interaction:
Former text replaced with shorter text and good practice note and
some cross-refs. Former 4.4.1 deleted
4.5. Web-Enabled Linking: Stuff about URI refs moved
section 2 to this section. Also changed "creates" to "constitutes"
a link. Indicate that hyperlink means user can interact with. Rewrite
of "Use of Hyperlinks" good practice note based on Bristol
discussion.
4.6.2 XML Namespaces. At end of section,
incorporated
text
proposed by NW
4.6.3 Links in XML:
Replaced the good practice notes with two new ones based on
Bristol
4.6.4. Namespace Documents: Edits to discussion
after story. Listed
OWL (updated to CR), XHTML, SCHEMA, RDDL. Added XMLSCHEMA reference.
Old section 4.10.1 deleted
4.6.5. Fragment Identifiers and ID Semantics: First two
paras edited.
4.6.6. Media Types for XML: Edits based on comments from
Chris Lilley and
Dan
Connolly
5 Conformance:
New section
. In this section,
entities likely to wish to claim conformance are listed. Notes in the
document are written in terms of these entities.
All end notes deleted or incorporated into the prose.
Incorporated editorial comments incorporated from David
Pawson, Tim Bray, and Norm Walsh.
Changes in 1
October 2003 Working Draft
Changes between
26 Sep 2003
Editor's Draft
and
1 Oct 2003
Working Draft
diff
).
Abstract: Incorporates Roy Fielding's suggestions. Also,
in first sentence, changed "that" to "which" based on
comments from Olivier Fehr
1: In the scenario, moved sentence on browser config from intro to
section 3.1, first para after first story box.
(Per
29 Sep tag
teleconf
1.1.1: Added ed note about relation of MUST/SHOULD to RFC2119
terms.
2: In first sentence of second para,
changed "forms" to "represents" when talking about link definition.
(Per
29 Sep tag
teleconf
.) Also, added text from RF to same para, second sentence
to end.
2.1: Changed "People and software" to Web agents in three places
based on
comments from DC
Left editor's note since that narrowing may be too much, given
the definition of "agent" does not include people.
2.4: Some editorial clarifications to good practice note.
(Per
29 Sep tag teleconf
2.4.1: Replaced first sentence of third paragraph about frag ids
with editors note: "Although
there is agreement within the TAG that format specifications
define fragment identifier syntax and semantics, the TAG has not
yet agreed on text regarding the relation between multiple
available representations (notably with incompatible
frag id semantics) and a given representation retrieved by
an agent." (Per
29 Sep tag teleconf
2.4.1: Per
comments from DC
in fourth bullet, changed "the URI" to "a URI"
2.5: Deleted "access method", but left access mechanism
(without definition).
(Per
comments from DC
).
2.6: Added editor's note about Moby Dick para:
"The TAG is not
yet satisfied with the paragraph on Moby Dick, as the ambiguity
lies with the English statements themselves." (Per
29 Sep tag teleconf
3: Added around media type
(based on
comments from DC
4.4: Added end note 10 about relation between text/ and XML formats,
with forward reference to section on media types for xml. (Per
29 Sep tag
teleconf
4.8: Based on
comments from DC
deleted end note about URI refs from the introduction and
moved/modified to this section. Also added end note at end
of paragraph.
Deleted this end note: "Access to the resource may require the use of more than one
protocol. For instance, as mentioned in section 1.2.2 of [ URI ], both
DNS and HTTP are typically used to communicate with an origin server
responsible for an "http" URI. Note also that other protocols than
HTTP may be used to interact with a resource identified by an "http"
URI." Replaced with two questions at end of section on Interaction:
Do specifications give me license to use any protocol
I want with a URI such as an "http" URI, where there is a strong
expectation that I will use HTTP? Are there practical examples
of this?
Access a the resource may require the use of more than one
protocol, so even though we may talk about "GET", several
protocols may be invoked. Does this need discussion?
Deleted old end note two,
per
29 Sep tag
teleconf
Changes in 26
September 2003 Editor's Draft
Changes between
18 Sep 2003
Editor's Draft
and
26 Sep 2003
Editor's Draft
diff
).
Status section: Shortened per
comments
from Roy
Abstract: Changed based on
proposal
from Roy
and discussion that followed on the list. Clearer
separation
between info space (Web), info systems (hyperlink Web, Sem Web,
Web Services), and architecture.
2.1: Changed title of good practice note to
"Compare URI Characters" per
comments
from Stuart
2.2: Based on
thread
on opacity
, added some text and an example:
Example of why software could infer mailboxes from "mailto"
But why this is risky.
Added good practice note basesd on SW text from opacity finding
draft.
2.3: Changed sentence about pre-Web info systems
per
comments
from Stuart
. Also change to mailto URI desc ("Internet" mailboxes)
and ftp URI desc (to talk about what's available via FTP
protocol).
2.3: Added this sentence to end of penultimate paragraph:
"Deployed software is more likely to handle the introduction of a new
media type than the introduction of a new URI scheme."
2.4.1: Deleted the following from beginning of second paragraph
after first bulleted list: "For URI schemes that do specify the use of
fragment identifiers" (per
comments
from Stuart
2.4.2: Based on
comments
from Stuart
changed "Clients can do something useful with the
fragment identifier and the SVG representation, since SVG defines
fragment identifier semantics."
to
"Clients can do something useful with
fragment identifiers if the media format used by the representation,
e.g. SVG, defines fragment identifier semantics."
2.4.2: Based on
comments
from Stuart
changed last sentence in second para to:
"...an error condition by making available PNG and JPEG/JFIF
representations in addition to SVG representations
since their fragment identifier semantics are not consistent."
2.5.1: Based on
comments
from Stuart
, added an end note (8):
"This is true even for HTTP PUT interactions,
for example, as the authority may configure the server
to accept or reject PUT data based on media type, validity
constraints, or other constraints."
3.1: Based on
comments
from Stuart
, fixed incorrect usage of "secondary resource";
changed to "another".
3.2: This was formerly section 4.1. Moved here per discussion
at face-to-face meeting in Vancouver.
4.2: Based on discussion with Dan Connolly, added more
argument to first para why silent recovery from error is harmful.
4.3: Minor tweaks to first paragraph
based on
comments
from Stuart
, but this section may require more clarification.
4.8: Editorial changes in second para
based on
comments
from Norm
Other editorial changes based on
comments
from Stuart
and
comments from Norm
part 1
and
part 2
Changed formatting of list of notes after TOC. There was not
much support for the table layout.
Changed formatting of stories and notes (to be consistent). There
was not much support for the icon I chose to indicate the story.
Changes in 18
September 2003 Editor's Draft
Changes between
1 Aug 2003 Editor's
Draft
and
18 Sep 2003 Editor's
Draft
diff
).
Abstract, intro: Revised based on comments
on
IJ's suggested revision
Introduction: Added a URI/Resource/Representation graphic
4.6/4.7: Per
4 Aug
2003 teleconf
, swapped these two sections.
4.9: Per
4 Aug
2003 teleconf
, split one good practice note into two: "Link
mechanisms" and "Web linking".
4.9: Per
4 Aug
2003 teleconf
, split one good practice note into two: "Link
mechanisms" and "Web linking".
4.9: Per
4 Aug
2003 teleconf
, section on hyperlinks into a generic section (4.9)
and an XML-specific section (4.10.3)
4.10.1: Per
4 Aug
2003 teleconf
, added definition of "XML-based" based on suggestion
from Tim Bray
4.10.2: Incorporated
text
from NW
. Per suggestion from Noah Mendelsohn, however,
changed "fully qualified" to "expanded name" in second paragraph.
4.10.4: Incorporated
text
from NW
, making some
changes suggested by TB
4.10.6: Per
4 Aug
2003 teleconf
, moved good practice note to end of section. Also
clarified when intermediaries can transcode; namely text/*.
Also appended "and will cause the document to be not well-formed" to
end of second paragraph. Also fixed information reg
3.1: Per
4 Aug
2003 teleconf
, moved old 3.1 to beginning of 3, and moved story
to 3.1. Also, fixed information regarding "Transfer-encoding". Also
clarified
three types of metadata (resource, representation, message)
Footnote 13: Added per
4 Aug
2003 teleconf
Other changes:
Incorporated
comments from Tim Bray
except the
following:
7.Didn't find.
12. As RF has pointed out, we also need a character delimiter (which
could also be "<>"
14. I made some changes regarding "component" and "user agent" but
there is a still a mix. I think we need to discuss whether and
when each usage is appropriate. See also point 26.
24. I left this. I anticipate discussion on this.
33. I think TB is incorrect on this point. HTML 4, for example,
defines the syntax of fragment identifiers that follow "#".
And RDF defines the semantics as identifying real world objects.
Is that really delegated by a URI scheme spec?
New table of good practice note links after TOC instead of
embedded in it.
Per
4 Aug
2003 teleconf
, identify when document enters "story mode". I used
an icon for this purpose.
Per
4 Aug
2003 teleconf
, changed "machine readable" to "optimized
for processors, with a definition that includes notion that
data can be process unattended by a person.
4.9: Per
4 Aug
2003 teleconf
, deleted Editor's note at end of section 4.10.1
Changes in 1 August 2003
Editor's Draft
Changes between
16 Jul 2003 Editor's
Draft
and
1 Aug 2003 Editor's
Draft
diff
).
Most of these changes were discussed at the TAG's 21-23 July face-to-face
meeting in Vancouver. Note that sections 3 and 4 were swapped since the 16
July draft. The numbers of sections below are those of the 1 August draft.
Abstract: Incorporated
text
suggested by Roy Fielding
Status: Moved some text from intro (on resolving differences with other
specs) to the status section.
1. Introduction: Incorporated
text
suggested by Roy Fielding
. This involved elaboration of the initial
scenario.
1.1 About this document: New introductory paragraph based on text from
Roy Fielding. Moved second paragraph (before 1.1.1) from later section to
1.1. Created new subsection 1.1.2 about scope (thus, two subsections
instead of 1).
2. Identification and Resources. Per
28
July teleconf
, changed "a shared set of bindings between identifiers
and things". However, since the text discussed at the teleconf was
awkward, edited to "a shared set of identifiers with agreed to meaning".
Deleted phrase "important resource" from "Use URIs" principle; instead;
talk specifically about when URI would be useful. After Principle, added
clear statement that a resource may be identified by more than one URI.
Added editor's note about "information resource" (and "on the Web").
2.1 Comparing identifiers. Simplified first paragraph. Changed
"Spelling" in good practice note to talk about URI characters, and
indicate where "URI character" is defined in [URI]. In fourth para,
simplified discussion of false positives and negatives.
2.2 URI Opacity: New section (from existing material). In editor's
note, added comment about not restricting URI space and reference to
siteData-26.
2.3 URI Schemes: Better use of "scheme" v. "scheme name". Did not
introduce "scheme component", however. Incorporated RF comment about
"information systems that pre-date the Web". Deleted sentence beginning
"We note in passing..." Deleted "Reasons for this include..." through
bulleted list, but moved first bullet to previous section on opacity.
Also added ref to metadataInURI-31 to editor's note. Edited good practice
note based on comments from TBL. Moves some additional points to section
3.3. (temporary holder).
Deleted old section 2.3 (on URI Authority), moving third and fourth
paragraphs to section on representations. Deleted reference
[IANAICP1].
2.4 Fragment identifiers now has two subsections.
2.4.1 Secondary resources identified through Fragment identifier:
Revised text based on text from Norm Walsh for first paragraph. The
bulleted list that follows is based on text from TBL. Deleted paragraph
"Although the generic URI syntax ... .specified for "mailto" URIs. from
old section 2.4.
2.4.1 Fragment identifiers and content negotiation: Strengthened
"clients should not be expected" to "It is an error"
in para before good practice note. Changed good practice note wording
re: frag ids and conneg.
2.5 Using a URI to Access a Resource. New section title. Deleted term
"URI resolution". Focus on "accessing the resource via the URI" instead.
In first paragraph, gave examples of HTTP methods for different examples
of access methods.
2.5.1 Retrieving a Representation. State clearly that HTTP POST with a
URI is not a representation retrieval for the resource identified by the
URI.
2.6 URI Persistence and Ambiguity. Added "Ambiguity" to section title.
Added new good practice note to avoid URI ambiguity. Modified example
following this good practice note. Added text on "indirect
identification" from TBL. Some edits to Moby Dick paragraph (but left
reference to "whale").
2.8 Future Directions for Identifiers: Added new intro paragraph.
Deleted old section 2.8.3 (on consistency of frag id semantics across
different media types), moving references to issue to earlier
sections.
3. Interaction. Added introductory scenario
material
from Tim Bray
3.1 Messages. Created new section for messages, with definitions of
"message data" and "message metadata" (still no illustration, though).
Refers to "octet sequence". Also refers to gzip transfer encoding (as
example of msg metadata).
3.2 REST: Created subsection for REST, but only has good practice note
in it.
3.3 Idea bin: Temporary section where some information from other
sections has been stored temporarily.
4. Representations and Formats. Added "Formats" to section title.
Definition of "Representation" now explicitly refers to sequence of
octets. Introduce terms "data format" and "format specification". Tie
"media type" to "data format". Added new paragraph about HTML and
flourishing of data formats. Include some references to general
information on good characteristics of a specification (last para before
4.1).
Note also that the TOC of section 4 has been rearranged somewhat based
on discussion at the ftf meeting.
4.1 Authoritative representation metadata. First paragraph moved here
from earlier section. Added paragraph with Oaxaca example after first
principle. Added second principle about servers not guessing metadata.
Other edits to this section based on comments from Roy Fielding. Added
some text about usability issues based on comments from Paul Cotton.
4.2 Interoperability and the use of Standard Format Specifications. New
title. Three bullet points elevated to good practice notes. Other bullet
points moved to other sections (4.9). Removed text about
author/user/programmer considerations.
4.3 Error handling. Added principle that silent recovery from error is
bad.
4.4 Information hiding. New good practice note (from existing text, but
edited).
4.6 Composition of Data Formats: Incorporated (and edited)
text
from Norm Walsh
4.7 Extensibility: Swapped first two sentences.
4.8 Presentation, content, interaction:
4.8.1 Final-form/reusable data formats: Moved from earlier in the
document.
4.9 Hyperlinks. New title (shorter, simpler). Created three good
practice notes from existing text.
4.10 XML-Based Data Formats: Edited first paragraph.
4.10.2 XML Namespace: Added some (short) Oaxaca scenario. Cut out a
number of paragraphs that didn't seem to add much. I think this section
needs a good practice note that format designers should enable the use of
xml namespaces.
4.10.3 Namespace documents. Added some Oaxaca scenario. Moved rationale
up. Added "machine-readable" to good practice note. Simplified paragraph
that follows good practice note.
4.10.5 Media Types for XML: Good practice note from existing text.
4.11: Added introductory paragraph.
Additional editorial changes:
s/relative URI/relative URI reference, but unsure which term will be
"correct one" since both appear in [URI]; I have pinged RF about
this.
Put URI scheme names in lowercase.
Deleted the term "agent" in favor of the term "component" based on Roy
Fielding text.
Deleted the term "language" in favor of "data format" and "format
specification".
Deleted the term "MIME" in favor of "Internet Media Type".
Added note and definition of URI reference.
Incorporated many
editorial
comments from Tim Bray
. Some of his suggestions were addressed at the
ftf meeting and are listed elsewhere.
Incorporated
editorial
comments from Stuart Williams
Incorporated
proposed
changes to references and acks from Paul Cotton
Changes in 16 Jul 2003
Editor's Draft
Changes between
15 Jul 2003 Editor's
Draft
and
16 Jul 2003 Editor's
Draft
diff
).
Editorial changes:
2: Editorial change to first sentence of paragraph based on
comments
from Stuart Williams
2.4.1: changed "URI makes sense" to "client can do something useful
with frag id."
2.5: Based on
comments
from Stuart Williams
, changed "operations are defined by" to
"available operations depend on."
2.5.2: Based on
comments
from David Orchard
, inserted an Editor's Note about "on the Web"
Changes in 15 Jul 2003
Editor's Draft
Changes between
27 Jun 2003 Working
Draft
and
15 Jul 2003 Editor's
Draft
diff
).
2. Identification and resources: Per comments from Karl Dubost and
Paul
Prescod
, added some characterization of how one might establish that
a resource is "important"
2.4 Frag ids: Per comments from Karl Dubost and Chris Lilley, added "or
the format he usually prefers."
3 Representations: Per
comments
from Roy Fielding
, distinguish metadata about representation/message
from metadata about data in a representation.
3.2.2.4 Extensibility and versioning: Added
text
from David Orchard
, but with substantial editing.
7.3 Non-normative references: Added EXTLANG and SOAP12.
General: Per
comments
from Stuart Williams
, made several changes to eliminate the phrase
"meaning of a resource"
General: Per
comments
from Roy Fielding
, made some changes regarding usage of "MIME type",
"content type", and "Content-Type".
General: Per
comments
from David Orchard
and Dan Connolly, decided to eliminate the phrase
"on the Web" since not critical to understanding the architecture.
Changes in 27 Jun 2003
Working Draft
There were no material changes between the
26 Jun 2003 Editor's Draft
and the
27 Jun 2003 Working Draft
Changes in 26 Jun 2003
Editor's Draft
Changes between
23 Jun 2003 Editor's
Draft
and
26 Jun 2003 Editor's
Draft
diff
The changes in this draft are editorial, based on
Dan
Connolly suggestions
and
Tim Bray
suggestions
. The primary changes are:
1. Introduction: In "2. Representation", added "servers" and changed
"represent, describe, and communicate" to just "communicate". Also,
changed "might have consisted" to "consists", i.e., made the example
concrete.
1. Introduction: Moved "Throughout this document, we elaborate on this
travel scenario to introduce and illustrate architectural principles." to
1.1
Merged 1.1.1 and 1.1.2
2. Identification and Resources: Moved intro paragraph from 2.1 to the
first paragraph. Per TB suggestion, deleted "The Web relies on a
worldwide agreement to follow the rules of URIs so that we can refer to
things on the Web, access them, describe them, and share them."
2. Identification and Resources: Changed "increases geometrically with"
to "grows exponentially as a function of"
2.1 Comparing identifiers: Tried to be clearer that "equivalence"
refers to "identifies the same resource". Comparing spelling is one way
to do that, there are other ways (e.g., in RDF).
2.2 URI Schemes. Clarification regarding IANA registry.
2.3 URI Authority. Moved info about DDDS to section on future work.
2.4 Fragment Identifiers. Moved concrete example up front. In second
paragraph deleted "Like the primary resource, the meaning of the
secondary resource is determined by the authority responsible for the
URI." I believe that Tim Berners-Lee had originally suggested some text
like this.
2.4 Fragment Identifiers. Cleaned up language in third paragraph;
pruned some text. Clarification about relation of frag ids to
intermediaries and redirection.
2.4 Fragment Identifiers. Modified good practice note so that no longer
requires "same" semantics; instead talk about "incompatible"
semantics.
2.5 Dereferencing URI. Deleted "URI" in front of first two terms since
took those terms from URI spec. Fixed third term to talk about
representation, not resource.
2.5.1. Retrieving a Representation. Fleshed out example of applying
specs.
2.5.2 Safe interaction. Fixed definitions of safe/unsafe interactions
per suggestions from Dan Connolly.
2.8.3 Title changed and added pointer to three issues instead of XHTML
and RDF example.
2.8.4 New section for DDDS reference
3.2 In bulleted list, harmonized language of last bullet on qnames with
other bullets.
4.1, 4.2 Deleted.
Changes in 23 Jun 2003
Editor's Draft
Changes between
16 Jun 2003 Editor's
Draft
and
23 Jun 2003 Editor's
Draft
diff
1: Moved introductory travel scenario to the very beginning of the
Introduction and pared it down. In bulleted list that follows about
tripod, refer to the pieces of the example.
1.1.1: Improved discussion about use of Arch Doc for communication and
dialog.
1.1.1: Deleted generic text about cost considerations. Instead, moved
comments about high cost of another (non-URI) identification system to
further down in the document in 2.1.
Per request from Dan Connolly, definitions of introduced terms are
marked up with dfn. There is now a generated index to these terms (and
the glossary has fallen into disarray for the moment).
2.1 New introductory text that attempts to give more rationale for why
useful to share identifiers (lower costs).
2.1: Although RFC2396bis says that it's "never possible to determine
that two URIs identify the same resource," softened this based on
comments from SW and DC. The TAG needs to talk about this.
2.1 good practice note: Removed second person usage.
2.1, last para: Made some minor clarifications in attempts to talk
generally about URI opacity.
2.2, 2.3 URI schemes: Lead with concrete example
2.4 Frag Ids: In RDF, frag ids refer to the subject of an RDF
description.
2.5.1 Retrieving a representation: In good practice note, changed
"nature and purpose" to (more general and used throughout the document)
"meaning".
2.5.2 Safe Retrieval: Gave an introductory definition of "safe
interaction".
3 Representations: Moved some information that was in initial scenario
description to intro of this section.
3.2: Added qname caution at end of bulleted list of suggestions
3.2.4: New text from NW.
Interaction: New first paragraph from RF.
6 Index: New
8 End Notes: New note about distinction between protocol used for
dereference and name of URI scheme
Changes in 16 Jun 2003
Editor's Draft
Changes between
26 Mar 2003
Working Draft
and
16 Jun 2003 Editor's
Draft
The primary changes in this draft are the result of the TAG walk-through
of the document at its
2 June 2003
and
9 June 2003
teleconferences. They include:
Abstract: Some editorial changes.
1.1 Scenario: Removed fragment identifier from example; reintroduced
later in the document. Domain name in example is now weather.example.com.
Throughout the document, based examples on this travel scenario.
1.2 About this document: Now subsumed under section 1.
1.2.2. Scope of this Document: Removed links to W3C Activities.
Instead, created references section for Architectural specs, and link to
that from section 1.2.2.
2. Identification and Resources. Incorporated a good bit of text from
RFC2396bis through section 2. Replaced references to RFC2396 with
references to [URI], and explain evolution of the URI spec in the
references section. In para 2 of 2.1, explained why assumption about
case-insensitivity incorrect.
2.2 URI Schemes. After good practice note, added discussion about reuse
of URI Schemes and registering new MIME type instead of URI scheme for
cost savings.
2.3 URI Authority. This is a new section.
2.4. Fragment Identifiers. Introduce notion of primary and secondary
resource taken from RFC2396bis.
2.4.1 Fragment identifiers and content negotiation. Created a
subsection for this topic.
2.5 Dereferencing a URI. Introduce terms resolution, dereference, and
retrieval as used in RFC2396bis.
2.5.2 Safe Retrieval. Fleshed out this section using some material from
draft TAG finding.
2.6 URI Persistence. New title for this section. Added namespace URI
issue to list of service breakdowns.
2.7 Access Control. Changed title of this section since really only
about access control. Added example using travel scenario in last
para.
2.8 Future directions for identifiers. New section. Moved information
about I18N of identifiers here. Added 2.8.4 based on 2 Jun teleconf.
Section 3 (Representations). This section almost entirely revised based
on
proposal from Tim
Bray
. Some headings reorganized by Ian.
3.2.1 Desirable Characteristics of Format Specifications. Added entries
for author and user needs. Deleted entry for examples based on R. Berjon
comment. Added information hiding entry (which was in another part of the
document before).
Section 3.3.2 XML Namespaces based on a
proposal
from Norm Walsh
3.4.1 Namespace document formats. Moved discussion of RDDL to future
directions section.
Added a number of references, notably in the section on Architectural
Specifications.
For now, removed markup for generation of glossary; todo later.
Additional editorial changes based on:
Graham
Klyne comments
Tim
Berners-Lee comments
Norm
Walsh comments
Tim
Bray comments
Changes in 26 Mar 2003
Working Draft
Changes between
21 Mar 2003
Editor's Draft
and
26 Mar 2003
Working Draft
Editorial changes per
24 Mar 2003
TAG teleconf
Removed summary list of principles. Instead, include short titles in
TOC and highlight them. Former text from list of principles now in
section 2.1 "About properties, constraints, principles, and good practice
notes"
Added header "1.1 Scenarios" to section on scenarios.
Changes in 21 Mar 2003
Editor's Draft
Changes between
21 Feb 2003
Editor's Draft
and
21 Mar 2003
Editor's Draft
and
Per discussion at the
17 Mar 2003 TAG
teleconf
, reinstated the intro paragraph from the 6 Feb 2003
draft.
However, also included an example of a common interaction (without much
transition to the rest of the document. Not sure the TAG will want this
example up front. Also, diagrams will be helpful, but I'd just as soon
wait until we agree on the text content.
Some information that was in the 21 Feb introduction has been moved to
the beginning of sections 3 and 4.
Changes in 21 Feb 2003
Editor's Draft
Changes between
6 Feb 2003
Editor's Draft
and
21 Feb 2003
Editor's Draft
Changes based on
Mark
Nottingham comments
on the
15 Nov 2002
draft
Listed in order of MN's suggestions:
Done
Not done pending larger work on categories
In section 3.2, included: "A URI scheme may specify semantics or syntax
constraints beyond those of [RFC2396]. For instance, a URI scheme might
specify the type of resource identified by such URIs, the desired
persistence of such URIs, or a default character encoding for URIs of
that scheme."
Agreed with reviewer's change: "A resource can be thought of as..."
Furthermore, in "Identification and resources," changed "Resource is" to
"Resource can be" (in 1.1) since that's a direct quote of RFC2396.
Per the
Feb 2003 TAG ftf meeting
, I think the TAG generally agrees with the
reviewer's comment. Consequently:
Moved sentence about metadata from this section to 1.2
Stated more clearly in 1.2 that metadata can be both about
representation and about message bearing the representation
One dereferences a URI, not a resource. To clarify distinction between
(generic) term derference and specific method of "retrieving a resource,"
moved some information around sections "Dereferencing a URI" and
"Retrieving a Representation." Also:
Rewrote this sentence to include "on the Web"; now part of section
1.1
Added following two sentences to section 3.4: "In general,
information about which dereference mechanism to use for a given URI
is not part of the URI, but specified by the context in which the URI
is used. Many format specifications include ways to refer to other
resources; agents processing those URIs generally dereference
them."
See new text in intro section 1.1: "On the Web, information about the
nature or state of a resource is communicated through representations,
not URIs. Consequently, the party authorized to make those
representations available determines the meaning of the resource, and
which URIs refer to it."
In light of discussions about "two primary uses of URIs" at the 7 Feb
TAG ftf meeting, the section formerly named "Uses of URIs" has been split
up and reorganized.
Comments on 2.5 no longer applicable (section deleted)
Added as an editorial note in section on URI schemes
Changes based on
comments from
Tim Bray
on 6 Dec 2002 draft
Deleted from old 2.2.1: "Fortunately, the problem does not need..." and
three of four items in bulleted list, per
7 Feb
2003 ftf meeting
3: Added Editor's note: "The TAG is following work on
"Internationalized Resource Identifiers (IRIs)" [IRI], which the TAG
considers to be a valuable mechanism for writing down URIs in an
international context. Please refer to TAG issue IRIEverywhere-27."
3.1: Shrunk substantially section on comparing URIs. Left a reference
to finding on comparing URIs.
3.1: Per
7 Feb
2003 ftf meeting
, tried to clarify first two paragraphs on what you
can tell by looking at a URI.
3.2: Per TB suggestion, made a bulleted list of (two) reasons not to
use unregistered URI schemes.
3.2: That ":" follows URI scheme name is now at beginning of 3.2
3.4.1: Changed ""When one resource refers to another"" to "When a
resource representation refers to a resource (by means of a URI)". This
may not be the best place for this; it might appear much sooner.
5.2: Added "CP9": "Designers of protocols SHOULD invest time in
understanding the REST paradigm and consider the role to which its
principles should guide their design:"
statelessness
clear assignment of roles to parties
uniform address spac
limited uniform set of verbs
Added editor's note to end of 5.3": Per their 27 Jan 2003 teleconf, the
TAG expects to add text about proper interpretation of protocol headers,
as discussed in "Internet Media Type registration, consistency of
use."
Changes based on discussion with Dan Connolly
To respond to requests to have more of a "Web model" up front, moved
some info from body up to introduction. This draft does not address the
question of the meaning and usage of principle/constraint, etc., however.
The intro has more of a story of what the Web is, still in terms of
ids/reps/protocols. This story followed by summary of properties.
1.4: Moved RFC2119 stuff to beginning. Added section on economics theme
to end
Created new section 2 ("About this document") since it didn't feel like
part of the Intro-with-story.
Rearranged a lot of (new) 3 so that syntax and things related to syntax
precede things related to interaction with resources.
Deleted example of W3C this version/latest version from section
3.4.4
Deleted some paragraphs per 6-7 Feb ftf meeting about "authoritative";
instead, say in 1.1: "On the Web, information about the nature or state
of a resource is communicated through representations, not URIs.
Consequently, the party authorized to make those representations
available determines the meaning of the resource."
3.1: New good practice note on spelling URIs, and reference to How to
Compare Uniform Resource Identifiers for details.
Moved URI scheme examples from beginning of old section 2 to new
3.2
Two new subsections just for safe retrieval and "identification is not
access" with a link to deep linking finding.
3.4.2: Changed from "Consistent representations" to "Servicing a URI"
Inconsistency not only source of problems. Changed good practice note
accordingly. Must text from persistence section (deleted) to 3.4.2, but
deleted example of this version/ latest version for W3C specs
Beginning of section 4 (Representations) now a bit hollow since some
text moved to intro
Other changes
1.1: Slight modification to definition of "agent":"Web agents (programs
acting on behalf of a person, entity, or process)" instead of "on behalf
of another person".
Also, put placeholders in for new issues since the previous draft.
Changes in 6 Feb 2003
Editor's Draft
Changes between
6 Dec 2002
Editor's Draft
and
6 Feb 2003
Editor's Draft
Suitable update to SOTD
3. Representations. Moved from 'media type' and 'bits' to 'media type
and other parameters' plus 'data (not necessarily described at the bit
level). Discussion at TAG f2f indicvates this change did not go far
enough; expect more changes here.
3.2. Processing model. Minor addition of xml:base as a second
example
3.3.1. When to use XML. Generally polished, added composability as
areason. Still don't understand what persistence and redundancey is on
about.Added XAG to informative references and referred to it from this
section.
3.3.2. XML Namespaces and Namespace Documents. Noted the need for prose
that explains the benefit of using an XML namespace as opposed to making
elements and attributes annonymous; following discussion about namespace
documents all well and good but somewhat moot unless a case is made for
namespaces in general. Added another note that ns-meaning can be done
without locking down a processing model. This section will also change
due to ns-meaningbeing split into three manageable chunks at the TAG
f2f.
3.4. Separating Content and Presentation. Start of major discussion on
what exactly content and presentation mean and to what extent they can be
separated; positioned as a continuum not a hard and fast rule. Included
an example. Do people like examples in this document?
3.4.1. Content, Presentation, and Interaction. This section got
smaller. By the time i am done editing it will be gone entirely.
3.5. Ideas and issues. Should have removed some of these as discussed
elsewhere; will do for next round.
4. Interaction.
Major
misunderstanding (cleared up at f2f)
about this section - I thought it was human-client interaction, actually
it is client-server interaction so all the new text here will wind up
someplace else.
7.2. Non-Normative References. Added XAG.
Changes in 6 Dec 2002
Editor's Draft
Changes between
15 Nov 2002
Working Draft
and
6 Dec 2002
Editor's Draft
1.3 Summary of terms. Moved intro paragraph to description of design
choices in new 6.1. Also, added links from category terms to descriptions
in 6.1.
2.1.1 Identity questions. New section based on
text
from DC
and material from deleted 2.5. I did not incorporate all of
DC's text about comparing URIs while we wait for TB's
finding on
URIEquivalence-15
2.2.1 Comparing identifiers: After good practice note, added two
paragraphs from DC material.
Deleted old section 2.2.5 per
18 Nov 2002 ftf
meeting
. Moved example to a paragraph of 2.2.4 starting "Ambiguous
descriptions of what a URI identifies increase the likelihood that two
parties will think the same URI identifies different resources". Edited
this paragraph to try to be clearer about "meaning by following
specifications" v. "meaning through use" (which is not authoritative).
Per
comments
from TB
2.2.5 Persistence: This section seemed different enough from preceding
paragraphs that it deserved its own subsection, even if there's no
principle (yet).
Deleted old section 2.5 ("Some generalities about URIs"); some material
moved to 2.1.1.
3.3.2 XML Namespaces and Namespace Documents: New section based on
text
from NW
(with his corrections and a few minor changes). Moved
namespaceDocument-8 issue placeholder here.
6. Glossary: Divided in two: category descriptions (based on comment by
David Orchard at
18 Nov 2002 ftf
meeting
) and technical terms.
7.2 Non-Normative References:
Added citation of "Guidelines For The Use of XML in IETF
Protocols." Referred to from 3.3.1 "When to use XML." Per
comments
from TB
Per comment from Misha Wolf, changed "URI's" to "URIs" in
[COOL]
Added OWL10 and DAMLOIL, referred to from 2.1.1.
Changes in 15 Nov 2002
Working Draft
Changes between
12 Nov 2002
Editor's Draft
and
15 Nov 2002
Working Draft
Per SW comment on 13 Nov, changed "operations on uri" to "use of uri"
in title of 2.2.
Edited section 5.1 on information hiding.
Changes in 12 Nov 2002
draft
Changes between
7 Nov
draft
and
12 Nov draft
1.1: Audience of this document. Replaced reference to RFC2026 with link
to IETF RFC repository, per
suggestion
from SW
2. Identification and resources. Fixes to description of meanings of
resources identified by URI schemes in first bulleted list. Deleted the
UUID URI since didn't predate the Web.
2.2. Operations on URIS: Changed "interaction with a resource" to
"dereference a URI" per
suggestion
from SW
. Similar change in title to section 2.2.2, and first sentence
of that section, which explains that to dereference is to follow
specs.
2.2.2 Dereferencing a URI: The text no longer says that th only way to
interact with a resource is through a representation. Instead: "A
"representation" is a data object that represents or describes a resource
state, and is the vehicle for conveying the meaning of a resource."
2.2.2 Dereferencing a URI: Deleted an example that seemed
irrelevant.
2.2.4, 2.2.5: Attempt to split discussion about "meaning" into two:
authoritative meaning (and why inconsistent representations harmful) and
"meaning through use" (and why inconsistency with authoritative meaning
harmful).
2.2.4: Added Moby Dick example (and deleted editor's note on this
topic) per
suggestion
from TB
2.3 Deleted constraint "Unregistered URI schemes MUST NOT be used on
the public Internet for general purpose applications." However, left
information about lack of guarantees if scheme not registered.
5 General design principles: Put initial text about information hiding
in this new appendix. Still rough.
Editorial:
Changed some instances of "addressable" to "identified" or
"identifiable" per
suggestion
from SW
Changed instances of "URN subclass" with "URN namespace identifier
(NID)" per
suggestion
from SW
Changes in 7 Nov 2002
draft
Changes between
7 Nov
draft
and
29 Oct
draft
This draft attempts to introduce a model offered by Roy Fielding of
distinguishing properties, constraints, and principles. I added to the
list "design choices" based on discussions with Tim Berners-Lee. The
(formerly all) principles have been recategorized per suggestions from
Roy. New style sheets highlight which class each item belongs to.
Changed the title from "Architectural Principles of the WWW" to
"Architecture of the WWW" per comments from Roy. Also, changed the titles
of sections 2, 3, and 4 based on Roy's comments.
1.1 Audience: Per comments from Alan Kotok and Daniel Dardailler, added
the beginnings of what one could call required reading prior to reading
the arch doc.
2. Identification and resources: Fixed what URIs identify in the first
bulleted list (e.g., not mailbox names but mailboxes). Deleted last
example since that one did not predate the Web.
2.2 Operations on URIs. This section has been somewhat rewritten in an
attempt to incorporate comments from Dan Connolly. See in particular
sections 2.2.4 and 2.2.5. There is an attempt to distinguish "meaning"
from the perspective of what specifications define, from "meaning" in the
way that URIs are used. As a result, there are two principles:
"Consistent URIs" and "Consistent representations". These replace the
former principle about ambiguity in use being harmful to people and
machines.
2.3 Per comments from Roy Fielding, I deleted the principle
"Unregistered URI schemes MUST NOT be used on the public Internet for
general purpose applications." Roy labeled this a "false constraint"
since this can be done in practice. However, left (edited) related text
in place (as it still makes sense).
2.5 Deleted first generality, as the question of authoritative meaning
is dealt with in 2.2.
5 Started new section for general design principles that cross borders
of sections 2, 3, 4. The only principle there so far is on "Information
Hiding", which is based on text from TBL.
Various editorial changes based on comments from Graham Klyne, Daniel
Dardailler, Paul Cotton, SVGDeveloper, and others.
Changes in 29 Oct 2002
draft
Changes between
29 Oct
draft
and
30 Aug 2002 first
public WD
From
28 Oct
teleconf
Clearer use of RFC2045/RFC2046; added reference to 2045.
Moved around a lot of material regarding consistency and
persistence (2.2)
For unregistered URI schemes, changed "MUST NOT be used on the
public Internet." to "MUST NOT be used on the public Internet for
general purpose applications."
Some editorial tweaks based on
Daniel
Dardailler comments
Some editorial and other changes based on
Graham
Klyne comments
. In particular, added back an end note about NIDs
(since we call URN namespaces "subclasses" rather than "namespaces" to
avoid confusion with xml namespaces).
Per
25 sep
2002 tag ftf meeting
, deleted section on URIs and
context-sensitivity.
Per
25 sep
2002 tag ftf meeting
, added a sentence example about safe
retrieval
Per
25 sep
2002 tag ftf meeting
, explain usage of URI in this document; explain
that coordination with IETF happening.
Per
25 sep
2002 tag ftf meeting
Started adding some notes about SMTP and the Web.
Added FTP to list of protocols in intro
Added reference to RFC1958 and cite it in intro
Per
25 sep
2002 tag ftf meeting
, per request from Joseph Reagle, changed "RDF"
to "RDF/XML" in list of formats in intro
Per
25 sep
2002 tag ftf meeting
, deleted information about REST from section on
protocols. Also, started new section in intro about
requirements/principles/ constraints and put reduced statement there that:
The principles in this document are based on experience. There has
been some theoretical and modeling work in the area of Web Architecture,
notably Roy Fielding's work on Representational State Transfer [REST].
Added some notes to chapter on formats based on discussion at
25 Sep 2002 TAG ftf
meeting
Per
25 sep
2002 tag ftf meeting
, used short titles for best practice notes. In
intro, new title "Scope of this document" * pointed out that
wai/i18n/devind being addressed elsewhere. * moved some text about
conflicts to after the list of principles
Per
25 sep
2002 tag ftf meeting
Merged principles 2/7 into "Ambiguity in the relationship between
URIs and resources is harmful for humans and machines." Still need to
figure out what to do with persistence section.
Removed reference to issue httpRange-14 since closed for now; no
consensus.