IJ and CL to draft a proposal to address this issue. (No clear direction from 14 May 2004 minutes, but there was discussion about whether the content was "designed for presentation".)
Write a draft finding on the benefits and limitations of the media type mechanism.
Propose additional text regarding separation of content and presentation that includes more about tradeoffs.
Propose three examples for section 3.3.2.
Rewrite story at beginning of 3.3.1. See resolution to delete "Note..." to end of the paragraph.
Draft text to explain that there's a tradeoff in this situation.
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.
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.
Ask reviewer if satisfied.
Propose editorial response.
Incorporated all of reviewer's suggestions.
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.
Ask the commenter if the definition in context (in section 3.1) explains the way we use the terms to his satisfaction.
[Empty]
Inform reviewer of TAG's decision.
[Empty]
Inform reviewer of TAG's decision.
Changed "unreliable" to "unpredictable" in 3.6 story. At their 13 May 2004 ftf meeting, the TAG discussed the use of both terms (unreliable and unpredictable) but did not come to a clear (revised) resolution.
Updated proposal
404 example included; both "reliable" and "unpredictable" used.
Inform reviewer of TAG's decision.
Created subsection 3.5.1 to distinguish topics of safe interaction and paper trail.
The TAG asked the Editor to edit this section to say that:
Respond to reviewer's comment that HTTP PUT/POST/DELETE do not work with URIs with fragment identifiers since HTTP does not give access to the secondary resource.
In section 3.3.1, included "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."
At their 13 May 2004 ftf, the TAG rejected the proposed text and asked the Editor to remove the sentence from the document.
Fix grammatical error in definition of "secondary resource" in section 5.
Fixed grammatical error.
Propose editorial response.
Agreed with reviewer; fixed text at beginning of section 2.
Remove the middle bullet from 2.3.
No more large number discussion. Left in mid/cid as examples where there is hierarchical delegation. Note the rationale for establishing uri/social entity relationship: "It is useful for a URI scheme to...". Not sure if that is sufficient....
Propose editorial response.
Adopted reviewer's suggested text in section 2.7.2 (third para). However, after 7 June 2004 teleconf, deleted the proposed paragraph.
Propose editorial response.
Adopted reviewer's suggestion to change "electronic data" to "data" in section 3.2.
Propose editorial response.
Eliminated unused concepts and reduced section 1.1.3. Reviewer satisfied.
Propose editorial response.
Did not change Error recovery GPN in section 1.2.3 per reviewer's suggestion, but text changed based on other comments.
The TAG believes that distinguishing "error correction" (errors that can be corrected as though they never happened) from "error recovery" (situations where the agent cannot correct the error) will improve the text. IJ to incorporate that change.
Incorporate change into text.
Extended language: A+B. Extension: B
Add a second paragraph to 1.2.4 explaining what TBL said about resilience as typical design goal in protocols.
Modified first paragraph to talk more about large-scale protocols v. traditional software APIs.
Propose editorial response.
In section 4.1, changed text in second para to "Increasingly, internationalized textual data formats refer to the Unicode repertoire [UNICODE] for character definitions."
Propose editorial response.
Adopted reviewer suggestion in principle of section 3.4.1 (consistent with other changes regarding authoritative metadata). Reviewer satisfied.
The TAG asked the Editor to compress sections 3.4 and 3.4.1 into a single section 3.4. The title of the section will be "Message semantics". Reviewer satisfied.
Discussion of "authoritative metadata" removed in favor of limiting discussion to that about data/metadata inconsistencies. Reviewer's comment about protocol semantics may be captured by first para.
Propose editorial response.
Attempted to following reviewer's suggestions. Eliminated "resource owner" in favor of "URI owner". Similarly, changed "user agent" to "agent" in GPNs. Changed "author" to "content author", "server manager" to "representation provider", and "developer" to "software developer". In the GPNs, changed "language designer" and "format designer" to "Specification" (as the subject). Moved note about format v. language to section 1.1.1 and introduced phrase "specification designer" as an encompassing term. Reviewer satisfied.
Propose editorial response.
Created a summary; probably not quite what reviewer wants.
Propose editorial response.
Added forward reference in section 3.6.1 per reviewer suggestion. Moved story from beginning of section 3.5 to a few paragraphs in. Moved one sentence from 3.5 story to section 3.5.1 story. Incorporated other editorial suggestions except the definition of Link in section 5.
Subsumed.
The word "understood" has been deleted in the rewrite.
Address reviewer's comments (see DC action).
Added "One particularly useful mapping in the case of flat namespaces is to combine the namespace URI, a hash ("#"), and the local name; see the section on XML namespaces for more examples."
Propose editorial response.
Changed titles of GPNs that reviewer wished changed. Now only using principle, constraint, good practice (in that order). Also highlighted in abstract.
Ask the reviewer to clarify the question. The TAG believe the reviewer has misunderstood the notion of "URI persistence".
[Empty]
Propose editorial response.
No change. It is probably useful to have a URI for a resource where language is content-negotiated, but it is also useful to have a URI for the "resource in language L".
Add some text that talks about content negotiation in addition to leaving the distinct URIs (one per language resource).
Deleted the language-specific URIs since they do not identify the same resource. Deleted the example but augmented the discussion of content negotiation per the 14 May ftf meeting.
Propose editorial response.
In section 3.4, Added "or transformed dynamically to the hardware or software capabilities of the recipient".
Add text to the document about media type limitations, versioning, and link to issue mediaTypeManagement-45.
Added: "Internet media type mechanism does have its limitations. For instance, media type strings do not support versioning or other parameters. The TAG issue mediaTypeManagement-45 concerns the appropriate level of granularity of the media type mechanism."
Include a reference to RFC2396 in the document. Inform reviewer of TAG's resolution.
Included reference to RFC2396 definitions of primary and secondary resource.
Respond to reviewer.
Incorporate DC suggested tweak for section 2:"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."
Incorporated.
Propose editorial response.
Good practice note in section 1.2.3 no longer talks about "silent recover" but rather recovery "without user consent". Added text 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." Updated GPN in section 3.4.1 as well.
Updated proposal
Distinguish error correction from error recovery.
Propose editorial response.
Attempt to soften claim about cost of overloading by adding "often" in first paragraph of section 2.2.
Updated proposal
Issue may be subsumed and mooted by this draft.
Propose editorial response.
I believe that edits to section 3.4 may satisfy the reviewer's comments; that text has been removed.
Propose editorial response.
Edited sentence in section 2: "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."
Propose editorial response.
In section 2.1.1, added last paragraph: "When a URI alias does become common currency, the URI owner should use protocol techniques such as server-side redirects to connect the two resources. The community benefits when the URI owner supports both the "unofficial" URI and the alias.".
Propose editorial response.
This draft addresses the reviewer's editorial comments.
The Editor believes this question is answered by the draft.
The Editor believes this question is answered by the draft: The string is compared character for character, and a URI string can include a fragment identifier.
Propose editorial response.
Removed contentious text from section 4.3. Text now reads: "Of course, it may not always be desirable to reach the widest possible audience. Designers should consider appropriate technologies for limiting the audience. For instance digital signature technology, access control, and other technologies are appropriate for controlling access to content."
Incorporate TAG's resolution.
Propose editorial response.
This draft incorporates reviewer's editorial suggestions.
Propose editorial response.
Good practice note in section 1.2.3 no longer talks about "silent recover" but rather recovery "without user consent".
Updated proposal
Distinguish error correction from error recovery.
Paste RFC2396 text in and ask the Schema WG to review.
In section 3.3.2, Added some text from RFC2396 bis per 3 May teleconf. The new text does NOT say "don't use content negotiation".
Delete "falling back to default behavior."
Deleted "falling back to default behavior" in section "Extensibility"
Insert a story in the section on extensibility about protocol extensibility.
Propose editorial response.
Per 22 March teleconf, deleted "that can be understood in any context" from section 4.5.3.
Incorporate changes per resolution.
Propose editorial response.
Adopted reviewer's proposal in section 4.5.3 to use "xsi:type".
Make changes to point to XML Schema spec (possibly with the xsi ns URI in text).
Para now starts: "The type attribute from the W3C XML Schema Instance namespace "http://www.w3.org/2001/XMLSchema-instance" ([XMLSCHEMA], section 4.3.2) is an example of a global attribute. It can be used by authors of any vocabulary to make an assertion in instance data about the type of the element on which it appears. As a global attribute, it must always be fully qualified. "
Propose editorial response.
Adopted reviewer's proposal in section 4.5.3: "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."
Clarify that this is an open issue.
In section 4.5.6, added note: "The TAG expects to continue to work with other groups to help resolve open questions about establishing "ID-ness" in XML formats." Also added fourth bullet per reviewer's suggestion.
Adopt text per TAG resolution.
New fourth bullet: "In practice, applications may have independent means (such as those defined in the XPointer specification, [XPTRFR] section 3.2) of locating identifiers inside a document."
Propose editorial response.
Adopted editorial suggestions except:
Propose editorial response.
Adopted editorial suggestion.
Might be subsumed.
Might be subsumed by new text in 2 and 2.1
Might be subsumed.
Might be subsumed by new text in 2 and 2.1
Revise the text of section 3.3.2 per the resolution. The editor notes that the future of the GPN in that section is uncertain.
Replace constraint at beginning of section 2 with a new principle and constraint:
Improve text regarding responsibility for inconsistent frag id semantics (looking at new RFC2396 text).
Add text from RFC2396.
In section 3.3.1 added text from RFC2396. Also 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."
Incorporate TAG resolution.
Incorporate resolution into section 3.6.2
Incorporate resolution.
Third bullet changed to: "The semantics of combining RDF documents containing multiple vocabularies is well-defined."
Create new section 4.6
New section created: "Data Formats Used to Build New Information Space Applications"
Edit "Parties that draw...." to be about drawing conclusions from syntactic analysis.
Adopt reviewer proposal.
GPN now reads: "A data format specification SHOULD provide for version information."
Delete "As part of defining ..." sentence.
Deleted "As part of defining an extensibility mechanism, specification designers should set expectations about agent behavior in the face of unrecognized extensions."
Comment addressed by this draft.
Comment addressed by this draft.
Merge sections 2 and 2.1
Deleted the example since these two URIs identify two different resources. This was part of a series of other changes to these early subsections of section 2. However, see section 3.3.2 for additional information on content negotiation.
Send TAG a draft of a response to Hammond review in light of TAG's discussion.
Inform reviewer of TAG's decision.
Send TAG a draft of a response to reviewer in light of decision.
Propose text on tradeoffs for section 4.2.2.
Write some text to address schema14 (e.g., by reviewing finding).
The TAG agreed with the proposal to add "necessarily".
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]
Respond to MD, acknowledging the dependency between arch doc and RFC2396bis.
See Reply from MD
Propose text for this issue. There is general support for a visibility principle.
Propose to the TAG a reponse to P. Stickler's message.
[Empty]
Respond to DB on TAG's choice of agent - the status quo.
Last update: $Date: 2004/08/10 13:11:54 $
This page was generated as part of the Extensible Issue Tracking System (ExIT)
Copyright © 2003, 2004 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.