Change history for Architectural Principles of the World Wide Web

This page is for maintaining a record of changes between each revision of
"Architectural Principles of the World Wide Web, produced by the TAG. If you find the list is incomplete or inaccurate
please send email to the TAG at www-tag@w3.org.

The pervasive nature of the changes in this draft make generating a colorized
"diff" version impractical.

----------------------------
revision 1.708
date: 2004/08/17 18:01:35; author: NormanWalsh; state: Exp; lines: +41 -109
Editorial changes from IJ
----------------------------
revision 1.707
date: 2004/08/17 17:31:58; author: NormanWalsh; state: Exp; lines: +43 -41
Another slug of editorial changes suggested by SW (mid:41218F7C.5000704@hp.com)
----------------------------
revision 1.706
date: 2004/08/17 14:43:47; author: NormanWalsh; state: Exp; lines: +29 -26
Editorial suggestions from SW (mid:E864E95CB35C1C46B72FEA0626A2E80803E3BC2E@0-mail-br1.hpl.hp.com) except ToC reorg
----------------------------
revision 1.705
date: 2004/08/16 19:29:22; author: ijacobs; state: Exp; lines: +1 -1
one more fix
----------------------------
revision 1.704
date: 2004/08/16 19:26:59; author: ijacobs; state: Exp; lines: +3 -3
tweaks to make a 16 Aug editor's copy
----------------------------
revision 1.703
date: 2004/08/16 19:21:32; author: ijacobs; state: Exp; lines: +23 -23
converted two-byte chars back to ascii
----------------------------
revision 1.702
date: 2004/08/13 17:15:41; author: NormanWalsh; state: Exp; lines: +1 -1
Fixed typo in URI
----------------------------
revision 1.701
date: 2004/08/13 15:37:28; author: NormanWalsh; state: Exp; lines: +4 -4
Fixed copyright, per pubrules
----------------------------
revision 1.700
date: 2004/08/13 15:32:30; author: NormanWalsh; state: Exp; lines: +141 -141
TOC reorg
----------------------------
revision 1.699
date: 2004/08/13 15:19:08; author: NormanWalsh; state: Exp; lines: +15 -108
Minor editorial tweaks
----------------------------
revision 1.698
date: 2004/08/13 12:17:40; author: NormanWalsh; state: Exp; lines: +2 -0
Snapshot
----------------------------
revision 1.697
date: 2004/08/12 19:44:06; author: NormanWalsh; state: Exp; lines: +17 -16
Pubrules tweaks to copyright and last version
----------------------------
revision 1.696
date: 2004/08/12 19:36:29; author: NormanWalsh; state: Exp; lines: +40 -23
Begin the pubrules dance
----------------------------
revision 1.695
date: 2004/08/11 17:18:33; author: NormanWalsh; state: Exp; lines: +103 -65
More f2f fiddling
----------------------------
revision 1.694
date: 2004/08/11 12:59:25; author: NormanWalsh; state: Exp; lines: +313 -112
Updated with 10 Aug changes:
I couldn’t check these in individually because of connectivity problems.
I fixed:
MSM5 -- editorial; provide an antecedent for "this property"; note that
there are multiple kinds of processing; make it clear that the subset
is extensible
MSM6, 5.2, make it clear that there should be a default action;
default depends on context (country code on a phone number in a
purchase order)
---
diwg1
New section in 3.6: Supporting Navigation
Add examples of URIs:
http://www.w3.org/TR/
http://maps.example.com/?lat=xxx,long=yyy,town=Cambridge,state=MA,country=US
http://maps.example.com/?sessnid=12345;userid=abcde
Inability to link to sub-pages of financial information
http://my.example.com/
---
diwg2
Chris to write text; will address content negotiated language selection
---
diwg3
Incorporate text from 2.2.3 of http://www.w3.org/TR/di-princ/
into our 4.3 and add a reference to di-princ.
---
manola27
Add to 3.6.2 that "that doesn't mean everyone has to know every URI"
or words to that effect. "Security considerations may require you
to keep some URIs secret"
change "but it is unreasonable to prohibit others from merely
identifying the resource" to "but merely identifying the resource is
like referring to a book by title. Except when people have agreed to
keep titles or URIs confidential, they are free to exchange them.
---
http://www.w3.org/2001/tag/webarch/July7-Aug10-diff.html
---
In 2.2, suggest changing "We use the term information resource to
refer to those resources for which you can retrieve a representation
over the network." to "A special class of resources, information
resources, is discussed in section 3.1. Information Resources and
Representations"
In 3.1, Information Resources are resources
that convey information. If a resource has a representation
then it is an information resource.
---
Although there are benefits (such as naming flexibility) to URI
aliases, there are also costs. Deployment of URI aliases raises the
cost or may even make it impossible for software to determine that
the URIs identify the same resource. URI owners should thus be
conservative about the number of different URIs they associate with
the same resource.
---
[URI aliases, 2.3.1]
URI aliases are harmful when they cause bifurcation in the web
of related resources. A corollary of Metcalfe's Principle
(the "Network Effect") is that the value of a given resource
can be measured by the number and value of other resources
that link to it (the network neighborhood of the measured resource).
This type of valuation is commonly used to rank the relative
value of search results (e.g., Google) because people tend to
create links relating a given topic to those resources that
they feel best reflect that topic, and hence the number of
inbound references are a reflection of the degree to which
the community values a resource. The problem with aliases is
that if half of the neighborhood points to one URI for a given
resource, and the other half points to a second, different URI
for that same resource, the neighborhood graph splits (bifurcates).
The aliased resource is not the only one undervalued because
of this split: the entire neighborhood of resources become
undervalued due to the missing second-order relationships that
should have existed among the referring resources by virtue of
their references to the aliased resource.
[note, aliases are also in 2.2 for some reason unknown]
---
In 2.3.2, change the story to to say that Dirk asks Nadia if
it matters which one she bookmarks.
---
In 2.5, remove (i.e., sequence of characters)
---
Rename, 2.5 URI Allocation
The URI spec[RFC2717,RFC2396] is an agreement about how the internet
community allocates names and associates them with protocols by
which they take on meaning; for example, the HTTP URI
scheme[RFC2616*] uses DNS in such a way that the names such as
http://somedomain/somepath#someFrag take on meaning by way of
messages from the domain holder (or somebody they delegate to).
While other communications (documents, messages, ...) may suggest
meanings for such names, it's a local policy decision whether those
suggestions should be heeded, while the meaning obtained thru HTTP
GET is, by internet-wide agreement, authoritative.
2.5.1 URI Ownership
A widely deployed technique to avoid URI overloading is delegated
ownership.
2.5.2 Other Allocation Schemes
UUID/MID; news:comp.text.xml has a social process for creating
them...
---
2.4 URI Collision
As discussed above, a URI identifies one resource. To use the same
URI to identify different resources produces a collision.
Suppose, for example, that one organization makes use of a URI to
refer to the movie "The Sting", and another organization uses the
same URI to refer to a discussion forum about "The Sting." This
collision creates confusion about what the URI identifies,
undermining the value of the URI. If one wanted to talk about the
creation date of the resource identified by the URI, for instance,
it would not be clear whether this meant "when the movie created" or
"when the discussion forum about the movie was created."
Principle: URIs identify a single resource
Assign distinct URIs to distinct resources.
---
3.3.1
In one of his XHTML pages, Dirk creates a hypertext link to an image
that Nadia has published on the Web. He creates a hypertext link
with Nadia's
hat. Emma views Dirk's XHTML page in her Web browser and follows
the link. The HTML implementation in her browser removes the
fragment from the URI and requests the image
"http://www.example.com/images/nadia" Nadia serves an SVG
representation of the image (with Internet media type
"image/svg+xml"). Emma's Web browser starts up an SVG implementation
to view the image. It passes it the original URI including the
fragment, "http://www.example.com/images/nadia#hat" to this
implementation, causing a view of the hat to be displayed rather
than the complete image.
Xref orthogonality from the following paragraph.
---
3.4
Incorporate Tim's text. Remove "documents" from expiry date.
Add pointers to relevant sections of http: and Apache docs.
---
3.5
reasons: document might be confidential, uri might be impractically
large
---
3.6
Delete "There are applications where it may be impossible or
impractical to provide a representation for every resource
(consider, for example, a system that used URIs to identify memory
locations in a running program). The fact that such applications
cannot provide representations should not discourage designers from
developing applications that treat them as web resources."
Change:
Principle: Reference does not imply dereference
An application developer or specification author SHOULD not require
networked retrieval to representations each time they are referenced.
Dereferencing a URI has a cost, potentially a significant cost,
perhaps in terms of security, network latency, or other factors.
Attempting to retrieve representations of resources when such
retrieval is not necessary should be avoided.
---
4.3
Change:
For instance digital signature technology, access control, and other
technologies are appropriate for controlling access to content.
to:
Designers should consider appropriate technologies, such as encryption
and access control, for limiting the audience
---
4.5.1
Salt again: The data's usefulness should outlive the tools currently
used to process it (though obviously XML can be used for short-term
needs as well)
Chris proposes: Need for data that can outlinve the applicatins that
produced it
---
Principle: Orthogonality
Orthogonal abstractions benefit from orthogonal specifications.
Experience demonstrates that problems arise where orthogonal
concepts occur in a single specification. Consider, for example, the
HTML specification which includes the orthogonal x-www-form-urlencoded
specification. Software developers (for example, of [CGI]
applications) might have an easier time finding the specification if
it were published separately and then cited from the HTTP, URI, and
HTML specifications.
Problems also arise when specifications attempt to modify orthogonal
abstractions described elsewhere. An historical version of the HTML
specification specified an HTTP header field ("Refresh"). The
authors of the HTTP specification ultimately decided not to provide
this header and that made the two specifications awkwardly at odds
with each other. HTML eventually removed the header.
(The problem here is the use of http-equiv with the value "refresh"
which *has no equivalent* in the http spec!)
---
Glossary:
Resource
[delete: A general term for ]Anything that might be identified by a URI.
----------------------------
revision 1.693
date: 2004/08/10 11:30:24; author: NormanWalsh; state: Exp; lines: +1 -1
Bumped date
----------------------------
revision 1.692
date: 2004/08/10 11:27:19; author: NormanWalsh; state: Exp; lines: +6 -6
Tweaked definition of information resource
----------------------------
revision 1.691
date: 2004/08/10 11:03:07; author: NormanWalsh; state: Exp; lines: +14 -5
Rearranged the definitional use of the word 'resource'; added text from 2396bis
----------------------------
revision 1.690
date: 2004/08/10 10:52:34; author: NormanWalsh; state: Exp; lines: +6 -0
Added an explicit note about using POST for safe operations
----------------------------
revision 1.689
date: 2004/08/10 10:47:26; author: NormanWalsh; state: Exp; lines: +8 -4
Added note about using URIs even when representations cannot be provided
----------------------------
revision 1.688
date: 2004/08/10 10:34:33; author: NormanWalsh; state: Exp; lines: +12 -33
Updated 5.1 to address nottingham1
----------------------------
revision 1.687
date: 2004/08/10 10:21:52; author: NormanWalsh; state: Exp; lines: +1 -1
Changed 'unknown elements' to 'unknown tags' to address msm7
----------------------------
revision 1.686
date: 2004/08/10 10:20:17; author: NormanWalsh; state: Exp; lines: +16 -0
Added good practice about server managers allowing users control of metadata to address msm4
----------------------------
revision 1.685
date: 2004/08/10 10:09:43; author: NormanWalsh; state: Exp; lines: +13 -0
Added good practice about unneccessary network access to address schema12
----------------------------
revision 1.684
date: 2004/08/10 10:00:35; author: NormanWalsh; state: Exp; lines: +27 -1
Added 2.3.2 Representation reuse to address schema3
----------------------------
revision 1.683
date: 2004/08/10 09:33:26; author: NormanWalsh; state: Exp; lines: +6 -0
Address klyne21
----------------------------
revision 1.682
date: 2004/08/08 18:54:59; author: NormanWalsh; state: Exp; lines: +36 -22
Addressed schema16, parsia11, klyne7, and klyne9. Integrated CL's updates to Section 3.3.1
----------------------------
revision 1.681
date: 2004/07/07 16:58:28; author: ijacobs; state: Exp; lines: +2 -1
tweak
----------------------------
revision 1.680
date: 2004/07/05 17:09:26; author: ijacobs; state: Exp; lines: +21 -21
link fixes
----------------------------
revision 1.679
date: 2004/07/05 16:51:50; author: ijacobs; state: Exp; lines: +1 -1
link fix
----------------------------
revision 1.678
date: 2004/07/05 16:50:03; author: ijacobs; state: Exp; lines: +2 -2
editorial
----------------------------
revision 1.677
date: 2004/07/05 16:49:37; author: ijacobs; state: Exp; lines: +2 -1
added statement that doc expected to become a rec
----------------------------
revision 1.676
date: 2004/07/05 16:47:55; author: ijacobs; state: Exp; lines: +2 -0
added statement that not covered by any w3c patent policy.
----------------------------
revision 1.675
date: 2004/07/05 16:31:42; author: ijacobs; state: Exp; lines: +1 -1
removed some nbsp
----------------------------
revision 1.674
date: 2004/07/05 15:48:51; author: ijacobs; state: Exp; lines: +1 -1
spell fix

----------------------------
revision 1.547
date: 2004/05/10 21:32:07; author: ijacobs; state: Exp; lines: +16 -16
Per 9 Feb 2004 TAG teleconf:
http://www.w3.org/2004/02/09-tag-summary.html
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,
http://www.w3.org/2004/03/02-tag-summary.html#stickler5
s/unreliable/unpredictable
----------------------------
revision 1.531
date: 2004/05/07 23:22:42; author: ijacobs; state: Exp; lines: +4 -1
http://www.w3.org/2004/05/03-tag-summary.html
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
http://www.w3.org/2001/tag/2003/lc1209/issues.html#parsia20
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
http://www.w3.org/2001/tag/2003/lc1209/issues.html#kopecky6
Maybe also
http://www.w3.org/2001/tag/2003/lc1209/issues.html#schema20
----------------------------
revision 1.506
date: 2004/05/07 20:10:03; author: ijacobs; state: Exp; lines: +0 -4
http://www.w3.org/2001/tag/2003/lc1209/issues.html#klyne12
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
http://www.w3.org/2004/05/03-tag-summary#klyne12
----------------------------
revision 1.505
date: 2004/05/07 20:08:52; author: ijacobs; state: Exp; lines: +2 -1
http://www.w3.org/2001/tag/2003/lc1209/issues.html#klyne11
Added "necessarily" per
http://www.w3.org/2004/04/26-tag-summary#klyne1
----------------------------
revision 1.504
date: 2004/05/07 19:24:08; author: ijacobs; state: Exp; lines: +11 -5
Editorial clarification for
http://www.w3.org/2001/tag/2003/lc1209/issues.html#msm3
----------------------------
revision 1.503
date: 2004/05/07 19:18:13; author: ijacobs; state: Exp; lines: +22 -19
Editorial changes based on
http://www.w3.org/2001/tag/2003/lc1209/issues.html#msm1
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
http://www.w3.org/2001/tag/2003/lc1209/issues.html#schema21
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
http://www.w3.org/2001/tag/2003/lc1209/issues.html#schema19
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
http://www.w3.org/2001/tag/2003/lc1209/issues.html#schema18
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
http://www.w3.org/2001/tag/2003/lc1209/issues.html#schema17
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
http://www.w3.org/2001/tag/2003/lc1209/issues.html#schema15
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
http://www.w3.org/2001/tag/2003/lc1209/issues.html#schema4
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
http://www.w3.org/2001/tag/2003/lc1209/issues.html#lesch1
----------------------------
revision 1.495
date: 2004/05/07 18:15:56; author: ijacobs; state: Exp; lines: +4 -5
http://www.w3.org/2001/tag/2003/lc1209/issues.html#gilman1
- 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
http://www.w3.org/2001/tag/2003/lc1209/issues.html#laskey1
----------------------------
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:
http://www.w3.org/2001/tag/2003/lc1209/issues.html#clark12
----------------------------
revision 1.492
date: 2004/05/07 18:01:24; author: ijacobs; state: Exp; lines: +3 -6
http://www.w3.org/2001/tag/2003/lc1209/issues.html#clark11
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
http://www.w3.org/2001/tag/2003/lc1209/issues.html#clark8
----------------------------
revision 1.490
date: 2004/05/07 17:52:02; author: ijacobs; state: Exp; lines: +1 -1
http://www.w3.org/2001/tag/2003/lc1209/issues.html#clark7
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
http://www.w3.org/2001/tag/2003/lc1209/issues.html#clark5
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
http://www.w3.org/2001/tag/2003/lc1209/issues.html#diwg3
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:
http://lists.w3.org/Archives/Public/public-webarch-comments/2004Feb/0031.html
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
http://www.w3.org/2001/tag/2003/lc1209/issues.html#duerst1
Changed indicated titles of GPNs
----------------------------
revision 1.478
date: 2004/04/28 20:31:40; author: ijacobs; state: Exp; lines: +26 -25
http://www.w3.org/2001/tag/2003/lc1209/issues.html#kopecky1
- 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
http://www.w3.org/2001/tag/2003/lc1209/issues.html#kopecky1
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
http://www.w3.org/TR/xmlschema-1/#Instance_Document_Constructions)
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
http://www.w3.org/2001/tag/2003/lc1209/issues.html#dhm7
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
http://www.w3.org/2001/tag/2003/lc1209/issues.html#dhm7
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
http://www.w3.org/2001/tag/2003/lc1209/issues.html#dhm7
---
* "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
http://www.w3.org/2001/tag/2003/lc1209/issues.html#dhm7
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
http://www.w3.org/2001/tag/2003/lc1209/issues.html#dhm7
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
http://www.w3.org/2001/tag/2003/lc1209/issues.html#dhm7
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
http://www.w3.org/2001/tag/2003/lc1209/issues.html#dhm6
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
http://www.w3.org/2001/tag/2003/lc1209/issues.html#dhm5
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.
http://www.w3.org/2001/tag/2003/lc1209/issues.html#hawke1
=======================
http://www.w3.org/2001/tag/2003/lc1209/issues.html#hawke6
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
http://www.w3.org/2001/tag/2003/lc1209/issues.html#hawke10
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
http://www.w3.org/2001/tag/2003/lc1209/issues.html#hawke9
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
http://www.w3.org/2001/tag/2003/lc1209/issues.html#hawke8
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
http://www.w3.org/2001/tag/2003/lc1209/issues.html#hawke7
----------------------------
revision 1.461
date: 2004/04/27 22:16:37; author: ijacobs; state: Exp; lines: +36 -40
Proposed fix to
http://www.w3.org/2001/tag/2003/lc1209/issues.html#hawke3
in previous edits.
In this draft, adopted SH proposal to s/URI ambiguity/URI overloading/
http://www.w3.org/2001/tag/2003/lc1209/issues.html#hawke4
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
http://lists.w3.org/Archives/Public/public-webarch-comments/2004Feb/0018.html
===========================================
== 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":
http://www.iana.org/assignments/urn-namespaces
http://lists.research.netsol.com/pipermail/urn-nid/2002-July/000308.html
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
http://www.w3.org/2001/tag/2003/lc1209/issues.html#hawke2
----------------------------
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.
http://lists.w3.org/Archives/Public/public-webarch-comments/2004Feb/0018.html
===========================================
== 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:
http://lists.w3.org/Archives/Public/public-webarch-comments/2004Feb/0018.html
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:
http://lists.w3.org/Archives/Public/public-webarch-comments/2004Feb/0018.html
===========================================
== 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:
http://lists.w3.org/Archives/Public/public-webarch-comments/2004Feb/0018.html
===========================================
== 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
http://www.w3.org/2001/tag/2003/lc1209/issues.html#pps1
----------------------------
revision 1.452
date: 2004/04/27 20:35:03; author: ijacobs; state: Exp; lines: +3 -3
Previous changes take into account these issues:
http://www.w3.org/2001/tag/2003/lc1209/issues.html#stickler5
http://www.w3.org/2001/tag/2003/lc1209/issues.html#stickler6
http://www.w3.org/2001/tag/2003/lc1209/issues.html#stickler7
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:
http://www.w3.org/2001/tag/2003/lc1209/issues.html#stickler2
http://www.w3.org/2001/tag/2003/lc1209/issues.html#stickler3
http://www.w3.org/2001/tag/2003/lc1209/issues.html#stickler4
http://www.w3.org/2001/tag/2003/lc1209/issues.html#stickler9
http://www.w3.org/2001/tag/2003/lc1209/issues.html#stickler10
----------------------------
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
http://www.w3.org/2001/tag/2003/lc1209/issues.html#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
http://www.w3.org/2001/tag/2003/lc1209/issues.html#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
http://www.w3.org/2001/tag/2003/lc1209/issues.html#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
http://www.w3.org/2001/tag/2003/lc1209/issues.html#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
http://www.w3.org/2001/tag/2003/lc1209/issues.html#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
http://www.w3.org/2001/tag/2003/lc1209/issues.html#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
http://www.w3.org/2001/tag/2003/lc1209/issues.html#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
http://www.w3.org/2001/tag/2003/lc1209/issues.html#goodwin1
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
http://www.w3.org/2001/tag/2003/lc1209/issues.html#booth3
"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
http://www.w3.org/2001/tag/2003/lc1209/issues.html#booth2
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
http://lists.w3.org/Archives/Public/public-webarch-comments/2003Dec/0019.html
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
http://lists.w3.org/Archives/Public/public-webarch-comments/2003Dec/0019.html
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
http://lists.w3.org/Archives/Public/public-webarch-comments/2003Dec/0019.html
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
http://lists.w3.org/Archives/Public/public-webarch-comments/2003Dec/0019.html
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
http://lists.w3.org/Archives/Public/public-webarch-comments/2003Dec/0019.html
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
http://lists.w3.org/Archives/Public/public-webarch-comments/2003Dec/0019.html
1.1.3:
s/<p>/p
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
http://lists.w3.org/Archives/Public/public-webarch-comments/2003Dec/0019.html
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:
http://www.w3.org/2001/tag/2003/lc1209/issues.html#karr1
----------------------------
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
http://www.w3.org/2001/tag/2003/lc1209/issues.html#harold1
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
http://lists.w3.org/Archives/Public/public-webarch-comments/2003Dec/0006.html
- 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
http://lists.w3.org/Archives/Public/public-webarch-comments/2003Dec/0006.html
Added World Wide Web, WWW, Web, and URI to the term index.

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

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.

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

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,
a TB
review,
TBL
review, and
SW
review.

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.

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

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

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

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.

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

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?

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

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.

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.

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

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

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

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

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

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"

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.

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.

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.

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

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.

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.

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

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.

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

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