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

Re: TAG ACTION-23: URIs for XML Schema datatypes

From: Jonathan A Rees <rees@mumble.net>
Date: Tue, 14 Feb 2012 12:57:18 -0500
Message-ID: <CAGnGFMLHmEMiC9z6mOmVQDCseK9fnYugvQ_NOsPvxmcqpN3F=w@mail.gmail.com>
To: "Henry S. Thompson" <ht@inf.ed.ac.uk>
Cc: www-tag@w3.org
On Tue, Feb 14, 2012 at 10:49 AM, Henry S. Thompson <ht@inf.ed.ac.uk> wrote:
> Jonathan A Rees <rees@mumble.net> writes:
>> On Tue, Feb 14, 2012 at 8:04 AM, Henry S. Thompson <ht@inf.ed.ac.uk> wrote:
>> ...
>>>  1) Because if we added such anchors they would be present in only one
>>>    of two content-negotiable representations retrievable from the
>>>    namespace URI, contra AWWW's statement that
>>>  "representation providers must not use content negotiation to
>>>   serve representation formats that have inconsistent fragment
>>>   identifier semantics" [5]
>> ...
>> AWWW 3.2 says that if a fragid is defined in one variant and not
>> another this is OK. That is, one of the variants is merely incomplete,
>> not inconsistent.
> I thought so too, at first, but then I concluded differently, and I
> just got off-track as I wrote it and failed to be clear.  But now I'm
> not sure all over again.
> Are we agreed on this much?: 3.2.2 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.

> So I think your critique is mistaken (also, because (1) is about the
> existing NS doc were anchors to be added vs the existing schema
> document).

I was thinking mainly about the situation where RDFa-style about=
definitions were added (to the HTML version only) compared to the
present where neither variant has fragid definitions. So that is a
different setup from what you were talking about, yes, but the same
considerations would hold talking about where anchors were added to
the HTML only, or to the schema but not the HTML. If you added anchors
to both the schema and the HTML, then you would risk inconsistency,
and as AWWW says some care would be required.

The key is the difference between "undefined"
(extension point) vs. "an error" (obligation to fail) as 3023bis would
have it. The web grows through extension points, the claim goes, and
it should be OK for clients (or formats, in this case) that don't understand
too-new features to ignore what they don't understand. (As we've seen this
idea has been called into question, but that's another story.)

Not saying I agree or not, just that this is how I read it.

The implications of either interpretation for the follow-your-nose
story are grave, as I've pointed out before. There is no request you
can make that will be sure of eliciting a definition, since the
definition can always reside in a version that you didn't happen to
get. Under your interpretation things are better but still not great.

My overall recommendation (for your followup on this) is to put about=
in RDFa in the HTML variant and leave the schema variant alone.


> But I still end up having made a mistake, because the _semantics_ of
> fragids are defined on both sides (by HTML and 3023(bis), as text/html
> and application/xml respectively, which _are_ consistent), so it's
> covered by 3.2.2 case 1.
> Sigh.
> I'll follow up.
> ht
> --
>       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 Tuesday, 14 February 2012 17:57:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:42 UTC