> On Tue, Feb 14, 2012 at 10:49 AM, Henry S. Thompson <ht@...> wrote:
>> Are we agreed on this much?: 3.2.2 [of AWWW] 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  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.
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
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."
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.
1) If X and Y are type-inconsistent for F, that's a "server
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. . .