- From: Henry S. Thompson <ht@inf.ed.ac.uk>
- Date: Wed, 15 Feb 2012 13:07:08 +0000
- To: Jonathan A Rees <rees@mumble.net>
- Cc: www-tag@w3.org
Jonathan A Rees writes: > On Tue, Feb 14, 2012 at 10:49 AM, Henry S. Thompson <ht@inf.ed.ac.uk> wrote: >> Are we agreed on this much?: 3.2.2 [of AWWW][1] is not about the >> _fragids_ being defined, but the _semantics_ of fragids in general >> being defined. > > No. I read it as quite strongly coming down on the side of individual > fragid definition consistency, with the implication that missing (of > any given fragid) is consistent with present (of the same fragid). > That just means the first media type and the documenta using it > haven't yet "caught up" with all the wonderful fragid defining > constructs in the second media type. But it may share some of the > constructs, and some of the fragid definitions. OK, so even though proof-texting is an obnoxious activity in general, I think we have to settle this independently of my haverings wrt the XML Schema namespace situation. My argument that 3.2.2 [1] is about media types, not about frag-ids, starts with this bit: "Individual data formats may define their own rules for use of the fragment identifier syntax for specifying different types of subsets, views, or external references that are identifiable as secondary resources by that media type. Therefore, representation providers must manage content negotiation carefully when used with a URI that contains a fragment identifier." We'll pass over the fact that as discussed at length in 3.2.1, the content _provider_ doesn't _know_ whether the client's view of the URI has a fragid or not. The point is that the focus here is on media types, and different _types_ of secondary resources. Second point: Case 1 in the analysis by cases in 3.2.2 "The interpretation of 'zicatela' is defined consistently by both data format specifications. The representation provider decides when definitions of fragment identifier semantics are are sufficiently consistent." talks about "fragment identifier semantics". Throughout 3.2.1, this phrase and variants thereof are used to refer to what a media type defines, that is, to something generic, not specific. Finally, in the discussion of case 2, we have "The second case is a server management error: representation providers must not use content negotiation to serve representation _formats_ that have inconsistent fragment identifier semantics." [emphasis added] This is the clincher, in my view. Not only do we have that key phrase, "fragment identifier semantics", appearing, but it's clearly stated that it's representation _formats_ which have such semantics, and it's at the level of formats that the inconsistency is a "server management error" == a violation of Web Architecture. ------------------- So I think we have the following picture, which independent of the above proof-texting exercise, I claim is correct on the merits. I'll use the designation "type-consistent for F" for two media types whose definitions of fragment identifier semantics for fragids of the form of F are (sc. ontologically) consistent. Type-consistency holds trivially if fragids of the form of F have _no_ semantics per one or both media types in question. I'll use the designation "token-consistent" for two fragment identifier referents (that which is "identified as [a] secondary resource", which I'll notate as |F| for fragid F in the context of some representation) which are (sc. identity-wise) consistent. It is of course contingent whether |F| is defined for a particular F and a particular representation. For a URI U of the form B#F, consider the case where RX and RY, representations of media type X and Y respectively, are served in response to HTTP GET requests for B subject to conneg. By cases: 1) If X and Y are type-inconsistent for F, that's a "server management error"; 2) If X and Y are type-consistent for F (which includes the case where they are identical), then by sub-cases: \ \ \ |F| def'd \ in RY | \ | |F| \ No | Yes def'd \ | in RX \ | -------|--------------------------------- | | No | OK | OK* | | ---------------------------------------- | | Yes | OK* | OK if token-consistent, | | representation author | | error otherwise OK*: Since RX may simply provide less information than RY and |F| is in the gap, for example. A few observations: The "server management error" attribution holds regardless of whether any URIs exist which would provoke a conflict, because they _may_ exist, and the server cannot know that they don't. The case where type-inconsistency is avoided only because one or both media types involved give no definition at all for fragids of the relevant form is in principle risky, as subsequent revision of the definition(s) of the media type(s) in question may provide one, as has happened with image/svg and is due to happen with application/xml. I find it helpful to note the distinction made here between server manager and representation author -- they may be the same, of course, but the difference in responsibility when they are different helps justify the story above. . . ht [1] http://www.w3.org/TR/webarch/#frag-coneg -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam]
Received on Wednesday, 15 February 2012 13:07:41 UTC