Re: Made rdf:HTML/XMLLiteral non-normative

On 16 Dec 2013, at 17:49, Markus Lanthaler <markus.lanthaler@gmx.net> wrote:
> On Monday, December 16, 2013 6:27 PM, Pat Hayes wrote:
>> What is non-normative about these is, RDF engines are not REQUIRED to
>> recognize them. But if they do, then they MUST get them right.
> 
> But that's exactly the problem. Since DOM4 is still in flux it will be
> impossible to "get them right". In other words, there's no stable (in W3C's
> definition of stable) algorithm to convert a lexical representation to a
> value yet. If you implement it today, you may end up with different results
> than someone who implements it tomorrow.

There’s two different concepts at play here.

We decided a long time ago to make both datatypes OPTIONAL, that is, implementations may decide not to support them. In other words, not recognise these datatype IRIs. This is not the issue at question here.

Then you made the datatypes NON-NORMATIVE on top of that, because they reference a bit of standards machinery that is still subject to change.

Now the problem is, in spec logic, informative material is irrelevant to the meaning of the spec. Removing all informative material cannot change what it means to conform to the spec. Someone interested in conformance never has to read informative material. Therefore, you cannot reference an informative section in a conformance statement (that is, a statement with MUST/SHOULD/MAY etc). For the same reason, putting a MUST into an informative section would be a logical error.

In my eyes, the correct thing to do is this:

1. Make the datatypes normative again
2. Define the value space and L2V mapping as “implementation-defined”
3. Add informative material that describes the DOM4-based implementations of these two concepts, and state that they are informative simply because the DOM4 spec is still subject to change at time of writing.

The result is that an implementation technically conforms to the spec regardless of how it implements the value space of these datatypes. That’s the best we can do. It doesn’t seem like a big deal, because actually implementing equivalence checking on these literals seems to have little benefit anyways.

There might be some editorially more elegant way to achieve the same result, but the current state, where the datatype doesn’t normatively exist at all, is rather bad IMO.

Best,
Richard

Received on Monday, 16 December 2013 18:56:21 UTC