This is the list of issues raised about the 9 Dec 2003 Last Call Working Draft of "Architecture of the World Wide Web". See also the annotated version of the specifiation, which includes issue text inline.
At its 4 Dec 2003 teleconference, the TAG resolved unanimously to advance "Architecture of the World Wide Web, First Edition" to Last Call status. Please send comments on the draft to the public mailing list public-webarch-comments@w3.org (archive).
For more information about the TAG, refer to the TAG Home Page.
Color key: error warning note
| Id:Title | State | Type | Open actions | Ack. |
|---|---|---|---|---|
| hammond1 : Distinguish normative/informative references? | declined | editorial |
| No response to reviewer |
| hammond2 : Editorial comments | no decision (raised) | editorial |
| |
| harold1 : Title of URI uniqueness constraint | agreed | editorial |
| No reply from reviewer |
| karr1 : What does "authority component" mean? | agreed | clarification |
| No reply from reviewer |
| ducharme1 : Editorial comments | agreed | editorial |
| No response to reviewer |
| worthington1 : Simplify the text and separate the W3C politics | declined | editorial |
| No response to reviewer |
| booth1 : Definition of "Web Agent" | declined | editorial |
| Agreement |
| booth2 : What rights does "URI ownership" confer? | agreed | clarification | Agreement | |
| booth3 : 4.5.4: NS document as definitive source of info on namespace | agreed | clarification | Agreement | |
| goodwin1 : Editorial suggestions | agreed | editorial | No response to reviewer | |
| stickler1 : Editorial suggestions | no decision (raised) | editorial | ||
| stickler2 : Sections 4.5.4, 5: Namespace document | declined | error |
| No reply from reviewer |
| stickler3 : Section 5: Dereference a URI | declined | editorial |
| No response to reviewer |
| stickler4 : Section 3.6.1 Proposed removal of good practice note | declined | request |
| No reply from reviewer |
| stickler5 : Section 3.6, para 1: Fix "resource is unreliable" | agreed | error |
| No response to reviewer |
| stickler6 : Section 3.5.1: POST requests and URIs | agreed | error |
| No reply from reviewer |
| stickler7 : Section 3.4, para 2: URI ownership questions | no decision (raised) | error | ||
| stickler8 : Section 3.3.1, last para, last sentence: Nature of secondary resource not known through URI | no decision (raised) | clarification |
| |
| stickler9 : Good practice note on URIs without fragids? | subsumed | proposal |
| |
| stickler10 : Section 5: Secondary resource | no decision (raised) | editorial |
| |
| pps1 : Ownership and authority | agreed | error | No response to reviewer | |
| hawke1 : Proposed good practice note on looking inside protocol interactions | subsumed | proposal |
| |
| hawke2 : Section 2: Full agreement not required for communication | subsumed | error |
| |
| hawke3 : 2.2 UUID/MD5 not registered URI schemes | no decision (raised) | editorial |
| |
| hawke4 : 2.3: Propose "URI overloading" not "URI ambiguity" | agreed | editorial | No response to reviewer | |
| hawke6 : 2.6. Fragment Identifiers: "Stem resource" | no decision (raised) | editorial | ||
| hawke7 : 2.7.2. Assertion that Two URIs Identify the Same Resource | subsumed | proposal |
| |
| hawke8 : 3.2. Messages and Representations: Use of "state" | no decision (raised) | editorial | ||
| hawke9 : 3.2. Messages and Representations | no decision (raised) | editorial |
| |
| hawke10 : 3.5. Safe Interactions | declined | editorial | No response to reviewer | |
| dhm1 : 1.1.3. Principles, constraints and good practices | no decision (raised) | editorial |
| |
| dhm2 : "Silent recovery from error is harmful" | no decision (raised) | editorial |
| |
| dhm3 : "Language extension" definition | agreed | editorial |
| No reply from reviewer |
| dhm4 : 1.2.4 Protocol based interoperability | no decision (raised) | editorial |
| |
| dhm5 : 4.1 Prevalence of Unicode | no decision (raised) | editorial |
| |
| dhm6 : Use of "server" in "...authoritative server metadata..." | no decision (raised) | clarification |
| |
| dhm7 : Webarch conformance model, subjects of GPNs | no decision (raised) | clarification |
| |
| weitzner1 : Proposed summary format | no decision (raised) | proposal |
| |
| rodriguez1 : Dataweb?: XDI and XRI. | declined | request | No reply from reviewer | |
| kopecky1 : Proposed to drop stories | no decision (raised) | editorial |
| |
| kopecky2 : 3.1 Reference or Identify? | declined | clarification |
| No response to reviewer |
| kopecky3 : 4 application/xml | no decision (raised) | clarification |
| |
| kopecky4 : 4.5.3 use of "understand" | no decision (raised) | clarification |
| |
| kopecky5 : 4.5.5 More info on qnames, fragids, ns docs | subsumed | request |
| |
| kopecky6 : 4.5.6 What's the conclusion? | subsumed | request | ||
| duerst1 : Principle and constraint titles | no decision (raised) | editorial |
| |
| duerst2 : WebArch and RFC2396bis: URIs and Fragids | no decision (raised) | editorial |
| |
| diwg1 : Add scenario(s) with dynamically generated URI | no decision (raised) | proposal |
| |
| diwg2 : Don't communicate language info in URIs (in example) | declined | error |
| No reply from reviewer |
| diwg3 : Suggest discussion of accessing different representations (transformed) of the same resource | no decision (raised) | proposal |
| |
| diwg4 : Suggest discussion of the limitations of Internet media types as the prime mechanism for selecting between different representations of a resource. | agreed | proposal |
| No reply from reviewer |
| clark1a : Fragment Identifier Semantics | agreed | clarification |
| No reply from reviewer |
| clark1b : Conflicting secondary resources | no decision (raised) | clarification | ||
| clark2 : What kinds of ambiguity are there? | no decision (raised) | clarification | ||
| clark3 : Willy-Nilly Resource Change | declined | clarification |
| No reply from reviewer |
| clark4a : Hypertext Good Practice Redundancies | declined | clarification | No reply from reviewer | |
| clark4b : "Expected UI Paradigm"? | no decision (raised) | clarification |
| |
| clark5 : Silent Error Recovery Always Harmful? | agreed | error |
| No reply from reviewer |
| clark6 : Separating Presentation From Content | no decision (raised) | clarification |
| |
| clark7 : More Ambiguity | no decision (raised) | clarification |
| |
| clark8 : Section 3.4.'s Unmotivated Paragraph | no decision (raised) | clarification |
| |
| clark9 : "Safe" and "Unsafe" Interactions | no decision (raised) | editorial | ||
| clark11 : The "great power" of URIs and their "vastness of choice" | no decision (raised) | editorial |
| |
| clark12 : Needless Propagation of URIs? | agreed | error |
| No response to reviewer |
| laskey1 : Editorial comments on WebArch | no decision (raised) | editorial |
| |
| laskey2 : What determines URI uniqueness? | no decision (raised) | clarification |
| |
| gilman1 : 'legal requirement' as justification for 'particular presentation' misses 'leading Web to highest' mark | agreed | error |
| No response to reviewer |
| gilman2 : orthogonality is not the answer | declined | error |
| No reply from reviewer |
| lesch1 : Editorial comments | no decision (raised) | editorial |
| |
| schema1 : [1.2.3] "Silent recovery from error is harmful." | subsumed | error |
| |
| schema2 : [Section 2] Unwise confluence of identification and retrievability | agreed | error | No response to reviewer | |
| schema3 : [Section 2.3] Clarity required on nature of "resource" | agreed | error | No response to reviewer | |
| schema4 : [3.3 Good practice: Fragment Identifier Consistency] | subsumed | clarification |
| |
| schema5 : [3.3.1] Inconsistency with RFC2396bis about frag id meaning? | agreed | error | No response to reviewer | |
| schema6 : [3.3.1] Do fragment identifiers work only with media-typed representations? | no decision (raised) | clarification | ||
| schema7 : [3.4.1] What is scope of metadata? | no decision (raised) | clarification | ||
| schema8 : [3.4.1] Authority and trust | subsumed | error | ||
| schema9 : [3.4.1] Are peer-to-peer interactions covered? | subsumed | error | ||
| schema10 : [3.5] Breadth of "safe" interactions | no decision (raised) | error | ||
| schema11 : [3.5.1] Best practice that content-location SHOULD be used? | no decision (raised) | clarification | ||
| schema12 : [3.6.1] [3.6.1] Good practice: Available representation. Too preferential to dereferencable URIs | agreed | error | No response to reviewer | |
| schema13 : [4.2] Overly simplifies a complex problem | agreed | error |
| No reply from reviewer |
| schema14 : [4.2.3] Must * rules in instance v. documentation | no decision (raised) | clarification |
| |
| schema15 : [4.2.4] SOAP message cannot include JPEG | declined | error | Agreement | |
| schema16 : [4.5.1] Section on when to use XML formats underdeveloped | agreed | editorial | No response to reviewer | |
| schema17 : [4.5.3] Statement about XMLNS and unique names false | agreed | error |
| No reply from reviewer |
| schema18 : [4.5.3] Clarification on "type" in XML Schema | agreed | clarification |
| Agreement |
| schema19 : [4.5.3] Element type/instance confusion | agreed | clarification |
| Agreement |
| schema20 : [4.5.6] Flavors of ID not discussed | agreed | error |
| No reply from reviewer |
| schema21 : General editorial comments | no decision (raised) | editorial |
| |
| lafon1 : Implications of HTTP URI implying GET as default method | no decision (raised) | editorial | ||
| msm1 : editorial comments on Web Architecture document | no decision (raised) | editorial | ||
| msm2 : WD-webarch-20031209, 1.1.3: Self-descriptive markup considered improbable | declined | error | No response to reviewer | |
| msm3 : WD-webarch-20031209, 1.2.1 para 1: Assigning identifiers without knowing about representations | subsumed | error |
| |
| msm4 : WD-webarch-20031209, 1.2.1, final bulleted list, final item.: Authoritative metadata and the principle of decentralization | agreed | error | No response to reviewer | |
| msm5 : WD-webarch-20031209, 1.2.2 para 5: Extensibility is a not a property of languages in isolation | no decision (raised) | error | ||
| msm6 : WD-webarch-20031209, 1.2.2 para 5: Ignoring the unknown as a default action | no decision (raised) | error | ||
| msm7 : WD-webarch-20031209, 1.2.2 para 6: Ignoring elements and ignoring tags | agreed | editorial | No response to reviewer | |
| msm8 : WD-webarch-20031209, Section 2, introductory paragraphs: The term 'resource' needs to be defined | no decision (raised) | error | ||
| msm9 : WD-webarch-20031209, Section 2 para 3: The vastness of URI space | subsumed | error |
| |
| msm10 : WD-webarch-20031209, Section 2: Assigning URIs to resources others will expect to refer to | subsumed | error |
| |
| msm11 : WD-webarch-20031209, Section 2.2, bulleted list, first item: Delegation of authority in hierarchical URIs | subsumed | error | ||
| msm12 : WD-webarch-20031209, Section 3.3.1, para 1: Are there constraints on the interpretation of fragment identifiers? | no decision (raised) | error | ||
| msm13 : WD-webarch-20031209, Section 3.3.2, para 3: Consistency of fragment identifiers | agreed | error |
| No reply from reviewer |
| msm14 : WD-webarch-20031209, Section 4.2.2, Story: Allowing extra attributes does change the conformance of existing data | declined | error | No reply from reviewer | |
| baker1 : Independence between identifier and resource, or representations? | subsumed | clarification | ||
| baker2 : More info on non-browser Web | subsumed | request | ||
| baker3 : Editorial comments | no decision (raised) | editorial | ||
| baker4 : 4.5.2: Preference for RDF linking over XLink linking | no decision (raised) | error | ||
| parsia1 : LC Comments: 1.2.1, editorial | no decision (raised) | editorial | ||
| parsia2 : LC Comment 1.3.1, editorial | no decision (raised) | editorial | ||
| parsia3 : LC Comment, 1.2.3: Principle: Error recovery | no decision (raised) | clarification | ||
| parsia4 : LC Comments, 1.2.4, editorial | no decision (raised) | editorial | ||
| parsia5 : LC Comment, Section 2: Agreement on identifiers | subsumed | error | ||
| parsia6 : LC Comment, Section 2: Identification mechanism of the Web | subsumed | error | ||
| parsia7 : LC Comment, Section 2: On requirement to assign a URI to a resource | subsumed | error |
| |
| parsia8 : LC Comment, Section 2: On resources existing before URIs | no decision (raised) | clarification | ||
| parsia9 : LC Comment, Section 2: On resources being able to have zero URIs | subsumed | error | ||
| parsia10 : LC Comment, Section 2: On URI assignment | subsumed | error | ||
| parsia11 : URI assignment v. use. Who are URI producers? | agreed | editorial | No response to reviewer | |
| parsia12 : Ambiguous use of URIs v. URI Ambiguity? | subsumed | error | ||
| parsia13 : Use of term "URI Space" | no decision (raised) | clarification | ||
| parsia14 : Various types of ownership | no decision (raised) | clarification | ||
| parsia15 : Social implications of URI ownership. | no decision (raised) | error | ||
| parsia16 : No conformance section? Guidance on usage then? | no decision (raised) | clarification | ||
| parsia17 : Do you mean resource or representation? | no decision (raised) | clarification | ||
| parsia18 : Temporal URL ambiguity useful for Web robustness? | no decision (raised) | clarification | ||
| parsia19 : Ok to infer properties of retrieved representations? | no decision (raised) | clarification | ||
| parsia20 : Drop definition of "on the Web" | subsumed | proposal | ||
| parsia21 : Drop sentence on successful communication | subsumed | proposal | ||
| parsia22 : What does "in general" mean? Would the case be different "in specific"? | no decision (raised) | clarification | ||
| nottingham1 : Second bullet doesn't make sense. | agreed | error | No response to reviewer | |
| nottingham2 : Include reference to IANA Registry of HTTP headers? | no decision (raised) | editorial | ||
| klyne1 : Proposed to drop para on view source or clarify role in webarch | no decision (raised) | clarification | ||
| klyne2 : Change "other operations" to "refer to in another way" | no decision (raised) | editorial | ||
| klyne3 : Proposal to improve text about "network effect" | no decision (raised) | editorial | ||
| klyne4 : Proposed rewrite of overlapping paras | no decision (raised) | editorial | ||
| klyne5 : Proposed to use "global across the Web" rather than "global" | no decision (raised) | editorial | ||
| klyne6 : Clarification about point on agents detecting equivalence relationships | no decision (raised) | clarification | ||
| klyne7 : Use other schema than mailto as example | agreed | editorial | No response to reviewer | |
| klyne8 : Unclear point about ambiguity in natural language; is the point about machine processing? | no decision (raised) | clarification | ||
| klyne9 : Add stronger language on not permitting unregistered URI schemes. | agreed | editorial | No response to reviewer | |
| klyne10 : Add cross-ref to section on orthogonality | no decision (raised) | editorial | ||
| klyne11 : Change "will result" to "will necessarily result" | agreed | clarification |
| No response to reviewer |
| klyne12 : Proposal to drop paragraph on inconsistent frag ids | subsumed | error |
| |
| klyne12b : Drop "by design" or replace with "by intent" | no decision (raised) | editorial | ||
| klyne13 : Text on communication between two parties misses mark about global names | no decision (raised) | clarification | ||
| klyne14 : Managers of resource, not Oaxaca | no decision (raised) | editorial | ||
| klyne15 : Lack of separation between owner of a resource and authority for a part of URI space used to identify a resource? | agreed | error |
| No reply from reviewer |
| klyne15b : Propose "rationally" instead of "predictably" | no decision (raised) | editorial | ||
| klyne16 : Proposed improved example about using content negotiation | no decision (raised) | editorial | ||
| klyne17 : Worth pointing out value of RDF descriptions depends on URI persistence? | agreed | proposal | No response to reviewer | |
| klyne18 : Use one of "data format", "format". And "language"? | no decision (raised) | editorial | ||
| klyne19 : Unclear statement about mixing RDF vocabularies | agreed | clarification |
| No reply from reviewer |
| klyne20 : Say something about relationship between Hypertext Web and Semantic Web? | subsumed | proposal |
| |
| klyne21 : Add statement about scalability concerns | agreed | proposal |
| No response to reviewer |
| klyne22 : Clarify what is meant by context having influence on use of hyperlinks | no decision (raised) | clarification | ||
| klyne23 : Clarify section (see TBL text on identifier v. reference?) | no decision (raised) | clarification | ||
| klyne24 : Is Web apart from Internet? | no decision (raised) | clarification | ||
| klyne25 : Add reference to RFC3117, section 5.1? | agreed | proposal | No response to reviewer | |
| klyne26 : Transcoding allowing by some or all intermediaries? | no decision (raised) | clarification | ||
| klyne27 : Clarify para on "text/" and US-ASCII encoding. How does it relate to following GPN? | no decision (raised) | editorial | ||
| manola1 : Use of "agent" as people+software is flaky throughout document. | no decision (raised) | editorial | ||
| manola2 : Clarify nature of resource in example | no decision (raised) | editorial | ||
| manola3 : Minor editorial comments | no decision (raised) | editorial | ||
| manola4 : Sentence about refs ends abruptly | no decision (raised) | editorial | ||
| manola5 : Sentence on understanding REST model unclear | no decision (raised) | clarification | ||
| manola6 : User agent any kind of agent or just software? What does "on behalf of" include? | no decision (raised) | clarification | ||
| manola7 : "Agent" or "user agent" meant? | no decision (raised) | clarification | ||
| manola8 : Add "(names for things)" after "identifiers"? | no decision (raised) | clarification | ||
| manola9 : Why use "third party"? Who are other two? | no decision (raised) | editorial | ||
| manola10 : Who are "designers"? Any diff between URI owner/producer? Relationship to resource owner? | no decision (raised) | editorial | ||
| manola11 : Proposed improvement to GPN on URI assignment | no decision (raised) | editorial | ||
| manola12 : URI producers or owners? Relationship to opacity principle? Evidence of confusion about "agent" including "people"? | no decision (raised) | clarification | ||
| manola13 : Can agents assign URIs? Or should this be "use"? | no decision (raised) | clarification | ||
| manola14 : Clarify relationship between resource / URI ownership | no decision (raised) | clarification | ||
| manola15 : Does example *also* illustrate ambiguous URI usage? | no decision (raised) | clarification | ||
| manola16 : Paragraph on other uses of URIs is confusing | no decision (raised) | clarification | ||
| manola17 : "Agent" that includes "people" source of confusion | subsumed | error | ||
| manola18 : Update references to RDF, OWL specs | no decision (raised) | editorial | ||
| manola19 : Please provide qualifying context about the nature of the Web | agreed | clarification |
| No reply from reviewer |
| manola20 : Have text after a story answer the question in the story. | no decision (raised) | editorial | ||
| manola21 : Owner of resource v. owner of URI | no decision (raised) | clarification | ||
| manola22 : "Agent" or "user agent" meant? | no decision (raised) | clarification | ||
| manola23 : Can software agents incur obligations? ("agent" or "user agent") | no decision (raised) | clarification | ||
| manola24 : What meaning(s) of "order" is meant? | no decision (raised) | clarification | ||
| manola25 : Agents "do not" or "should not" incur obligations? | no decision (raised) | clarification | ||
| manola26 : What does last sentence of story have to do with story? | no decision (raised) | editorial | ||
| manola27 : Provide examples of mistaken attempts to restrict URI usage | no decision (raised) | proposal | ||
| manola28 : Another case of "agent includes people?" doubt | no decision (raised) | editorial | ||
| manola29 : What are "language instances"? | agreed | clarification |
| No reply from reviewer |
| manola30 : Difference between "setting expectations" and "specifying"? | agreed | clarification |
| No reply from reviewer |
| manola31 : Questions about RDF, text, XML mixing | agreed | clarification | No reply from reviewer | |
| manola32 : Reword to avoid rhetorical question | no decision (raised) | editorial | ||
| qawg1 : Seeking liaison on definitions of extensibility w.r.t. QA Guidelines | no decision (raised) | clarification | ||
| i18nwg1 : Use "language" for natural language and "format" for format | no decision (raised) | editorial | ||
| i18nwg2 : Use "language" for natural language and "format" for format | no decision (raised) | editorial | ||
| i18nwg2b : Oaxaca hard to pronounce; propose Lima | no decision (raised) | editorial | ||
| i18nwg3 : Please show charset in Content-type. | no decision (raised) | editorial | ||
| i18nwg4 : Please refer to "issues" rather than "limitations" | no decision (raised) | clarification | ||
| i18nwg5 : Discussion of content-type header hint | no decision (raised) | error | ||
| i18nwg6 : Say something about character encoding/labeling errors. | no decision (raised) | editorial | ||
| i18nwg7 : Mention language negotiation | no decision (raised) | editorial | ||
| i18nwg8 : Sentences seem contradictory | subsumed | error |
| |
| i18nwg9 : Case example unclear. | no decision (raised) | clarification | ||
| i18nwg10 : Don't recommend organizing information by language. | no decision (raised) | clarification |
| |
| i18nwg11 : Mention IRIs? | no decision (raised) | clarification | ||
| i18nwg12 : Clarification on reference to "character" | no decision (raised) | editorial | ||
| i18nwg13 : URI ambiguity ambiguous | no decision (raised) | editorial | ||
| i18nwg14 : Show examples of good and bad ambiguity | no decision (raised) | clarification | ||
| i18nwg15 : Missing word | no decision (raised) | editorial | ||
| i18nwg16 : Good practice on URI opacity impossible to follow for humans. | subsumed | error | ||
| i18nwg17 : Add mention of IRIs | no decision (raised) | editorial | ||
| i18nwg18 : Mention that editing tools may be more strict than simple user agents | no decision (raised) | editorial | ||
| i18nwg19 : text/foo+xml considered useless? | subsumed | proposal | ||
| i18nwg20 : text/foo+xml considered useless? | no decision (raised) | proposal | ||
| rdfcore1 : RDF Core general comments | no decision (raised) | editorial | ||
| dubinko1 : Document different interpretations around httpRange-14 | no decision (raised) | editorial | ||
| dubinko2 : Architecture v. Building Codes | no decision (raised) | editorial | ||
| falstrom1 : Editorial comments | no decision (raised) | editorial | ||
| falstrom2 : SOAP as a different thing than the other protocols | no decision (raised) | clarification | ||
| falstrom3 : Separate Media Types and Frag Id discussion | no decision (raised) | editorial | ||
| falstrom4 : Show only good practice re: Content-Location | no decision (raised) | editorial | ||
| falstrom5 : Add discussion about SSL/TLS? Is title correct? | no decision (raised) | editorial | ||
| falstrom6 : List overall diffs between binary and text formats | no decision (raised) | editorial | ||
| falstrom7 : Indicate when to use different link types | no decision (raised) | editorial | ||
| rosenberg1 : Introductory para on Web overly broad? | no decision (raised) | editorial | ||
| rosenberg2 : RFC2119 terms meant for protocols | no decision (raised) | editorial | ||
| rosenberg3 : Reuse appropriate URI schemes (and protocols) | subsumed | proposal | ||
| rosenberg4 : Use SIP for voice-over-ip, RTSP for streaming media | no decision (raised) | clarification | ||
| rosenberg5 : Proposed reference to IANA registry for namespaces and RFC 3688 | agreed | editorial | No response to reviewer |
Would it be appropriate to distingush between normative and non-normative (i.e. informative) references?
The TAG does not feel an informative/normative split is justified.
Send TAG a draft of a response to Hammond review in light of TAG's discussion.
The reviewer made a number of editorial suggestions.
Propose editorial response.
Implemented:
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." Rationale: We used to have that and then chose the current organization instead."
Did not implement: "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?" Rationale: "We have examples of other schemes. No need to use exotic schemes if not motivated by story.
Did not implement: "Sect 2.4, 3rd para, 1st sentence, 'While the Web architecture...' - change 'is costly' to 'can be costly'?". Rationale: Not sure about this change.
Did not implement: "Sect 2.4, 3rd para, 3rd sentence, 'Introducing a new URI scheme...' - change 'requires' to 'may require'?" Rationale: Not sure about this change.
Did not implement: "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." Rationale: Nonetheless, the statement is true.
Did not implement: "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." Rationale: The TAG did not agree to that definition.
Did not implement: "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.)" Rationale: Having reread the sentence, I don't believe that's necessary. It's defined clearly.
Did not implement: "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?" Rationale: I think that's a qname rather than a qualified name.
"Constraint: URI uniqueness" is defined:
Web architecture does not constrain a Web resource to be identified by a single URI.
The constraint and the title do not seem to match. Perhaps the title is supposed to be "URI non-uniqueness" or perhaps the text is supposed to be something like "Each URI identifies exactly one resource". However, the title suggests to me that URIs are unique, and the text suggests the opposite.
At their 12 May 2004 TAG teleconference, the TAG resolved to demote the first constraint of section 2.1 to a sentence.
Propose editorial response.
In section 2.1, changed title of constraint to URI multiplicity.
Incorporate TAG resolution.
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.
In section 2.1, "URI Comparisons", I understand the meaning of the paragraph which begins "Applications may apply rules ...". It means that if your application makes assumptions about URI equivalences based on details not covered in the specification, then it's your responsibility if any problems develop from that. What I don't understand is the term "authority component" in this sentence:
For example, for "http" URIs, the authority component is case-insensitive.
The TAG agreed with the Editor's change to include parenthetical.
Propose editorial response.
In section 2.1, included a parenthetical explanation of what the generic "authority component" is.
The TAG agreed with the Editor's change to include parenthetical.
Ask reviewer if satisfied.
The reviewer made a number of editorial suggestions.
The Editor will take these comments into account.
Propose editorial response.
Incorporated all of reviewer's suggestions.
Split document in two: architecture, rationale
The TAG believes the document has an appropriate quantity/level of examples. However, the reviewer has said: "Thanks, I am satisfied that you have given my comment serious consideration. But as is I don't see the document as being workable, so I will not be recommending use of the Architecture to my students, colleagues or clients."
Respond to Tom Worthington, talking about arch doc / findings balance, and pointing out that we are not creating a point-form architectural thesis.
[Empty]
[Empty]
Should not include people
The TAG defends its definition of "agent" as including people.
Does not object to the definition
Respond to DB on TAG's choice of agent - the status quo.
Following the lessons of the "deep linking" debacle, it might be good to say explicitly what rights "URI ownership" does or does not confer. This is somewhat addressed later, but it might be good to say something in this section.
The Editor will include a forward link from 2.2 to 3.6.3.
Satisfied with editorial change in 10 May 2004 draft.
Include forward reference.
In section 2.2, included a forward reference to section on URI ownership.
Incorporated in 10 May 2004 draft.
However, the term "definitive" is missing. Was this intentional? Based on a quick skimming of the issue, it looks like the TAG is in agreement that the namespace document should directly or indirectly provide *definitive* material about the namespace, but I'm not sure.
The TAG agrees but for consistency prefers the term "authoritative".
Satisfied with editorial change in 10 May 2004 draft.
Refer to provider's namespace information as "authoritative".
In section 4.5.4, edited good practice note to say that: "When a namespace representation is provided by the namespace URI owner, that material is authoritative.
Also, globally changed the term "resource owner" to "uri owner" and clarified usage of "authority responsible for domain X" in the document.
The TAG accepted the proposal.
The reviewer made a number of useful editorial suggestions.
The Editor will take these comments into account.
Account for these comments.
Took into account all of the reviewer's suggestions. In particular, reorganized section 2.1 to read more clearly. Created a new subsection (2.1.1) out of the second half.
Incorporated in 10 May 2004 draft.
The reviewer made a number of useful editorial suggestions. This issue addresses those editorial points in the initial email not covered by other issues.
Incorporated editorial suggestions.
Incorporated in 10 May 2004 draft.
.. It is incorrect to suggest that there is any semantic relation between the meaning of a URI used as a namespace name and the meaning of terms grounded in that namespace...
Strongly advise the removal of both this term from the publication entirely but particularly this incorrect definition (see discussion above). The assertion that every URI used as a namespace name denotes a namespace document is false.
Adopt the following definition as a substitute for namespace document: "If a namespace declaration binds a prefix to a URI, and that URI can be dereferenced to get a representation, then that is a namespace representation."
Inform reviewer of TAG's decision.
Incorporated editorial suggestions.
Substitute "namespace representation" for "namespace document". The TAG discussed this edit briefly at their 12 May 2004 ftf meeting. There was no resolution, but the editor suspects that the change will be undone in subsequent drafts along with other changes regarding "information resources".
New proposal
First two paras edited so description of XML Namespaces has changed.
Consider expanding to "Indirectly access the resource identified by the URI via a representation of that resource."
The definition makes sense in the full context of the document; the TAG recommended no change to the glossary.
Consider change
The Editor considered and did not adopt the proposed change for the definition of "dereference a URI": "Indirectly access the resource identified by the URI via a representation of that resource."
The TAG agreed with the editor's choice not to change the glossary entry.
Ask the commenter if the definition in context (in section 3.1) explains the way we use the terms to his satisfaction.
[Empty]
Owners of URIs should be free to decide whether any representations are made available, and should *NOT* feel obligated to provide representations if they themselves have no need to do so. URIs without representations may simply be less valueable/useful than those with representations. But it shouldn't be considered bad practice to not provide any representations. I recommend that this particular "good practice" be removed, even though language should remain which reflects that URIs with accessible representations are usually more useful than those without.
The TAG intended to indicate that people SHOULD provide representations; the community is poorer where representations are not available. "SHOULD" allows URI owners to make a choice.
Inform reviewer of TAG's decision.
[Empty]