W3C home > Mailing lists > Public > www-tag@w3.org > February 2012

Consistency, Conneg and AWWW (was Re: TAG ACTION-23: URIs for XML Schema datatypes)

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
Message-ID: <f5baa4k8cub.fsf_-_@calexico.inf.ed.ac.uk>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:45 GMT