TAG Issues List for Last Call of 9 December 2003 Webarch

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

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

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

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

Clarification concerning

3.3.1. Media Types and Fragment Identifier Semantics

Discussion history

9 Feb 2004, 3 May 2004

Transition history

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

Action history

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

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

Clarification concerning

3.4.1. Inconsistencies between Metadata and Representation Data

Transition history

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

Action history

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

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

Transition history

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

Action history

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

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

Clarification concerning

4. Data Formats

Discussion history

13 May 2004

Transition history

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

Action history

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

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

Clarification concerning

4.5.3. XML Namespaces

Transition history

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

Action history

clark1b: Conflicting secondary resources [link to this issue]

See writeup from KC.

Clarification concerning

2.6. Fragment Identifiers

Discussion history

14 May 2004

Transition history

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

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

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

Clarification concerning

2.3. URI Ambiguity

Transition history

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

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

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

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

Clarification concerning

4.4. Hypertext

Transition history

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

Action history

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

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

Clarification concerning

4.3. Separation of Content, Presentation, and Interaction

Discussion history

14 May 2004

Transition history

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

Action history

clark7: More Ambiguity [link to this issue]

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

Transition history

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

Action history

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

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

Transition history

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

Action history

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

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

Clarification concerning

2.1. URI Comparisons

Transition history

raised on 1 Mar 2004 by Ken Laskey

Action history

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

[3.3.1] says

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

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

Clarification concerning

3.3.1. Media Types and Fragment Identifier Semantics

Transition history

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

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

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

Clarification concerning

3.4.1. Inconsistencies between Metadata and Representation Data

Transition history

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

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

[3.5.1] Says:

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

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

Clarification concerning

3.5.1. Unsafe Interactions and Accountability

Transition history

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

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

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

Clarification concerning

4.2.3. Extensibility

Discussion history

14 May 2004

Transition history

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

Action history

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

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

See issue clark5.

Clarification concerning

1.2.3. Error Handling

Transition history

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

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

Resources exist before URIs;

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

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

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

my_object_uri.assigned_to(my_funky_object)

is broken in some way? Why would this matter?

Clarification concerning

2. Identification

Transition history

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

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

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

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

Clarification concerning

2.3. URI Ambiguity

Transition history

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

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

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

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

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

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

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

Clarification concerning

2.2. URI Ownership

Transition history

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

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

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

Clarification concerning

1.1. About this Document

Transition history

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

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

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

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

Clarification concerning

2.5. URI Opacity

Transition history

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

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

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

I just wonder how this is different from:

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

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

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

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

Clarification concerning

2.5. URI Opacity

Transition history

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

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

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

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

Clarification concerning

2.5. URI Opaci