Re: Made rdf:HTML/XMLLiteral non-normative

Hi Markus,

So the only options that I can see are:

1. make *every mention* of the datatypes in *all* the specs informative, including Semantics and RDF/XML,
2. normatively define the datatypes, but make *only* the value space and L2V space informative (see below),
3. create a specification that is internally inconsistent and hope that nobody notices or cares.

I don’t know if the first option is viable, because no normative definition can depend on anything informative, so we might just end up pushing the problem deeper and deeper.

I happen to care a lot about internal consistency, that’s why I’d really rather not go down the third route.

More on the second option below.

On 17 Dec 2013, at 16:44, Markus Lanthaler <markus.lanthaler@gmx.net> wrote:
>>> So, to move forward, my proposal would simply be
>>> 
>>> PROPOSAL: Drop the "If the IRI ...#XMLLiteral/#HTML is recognized then
> it
>>> refers to the datatype rdf:XMLLiteral/rdf:HTML" statements in section
> 5.4 of
>>> RDF Concepts.
>> 
>> In that case, an implementation that accepts "<not>well-
>> formed"^^rdf:XMLLiteral would be conforming. This behaviour would not
>> constitue a bug. It would not be broken.
> 
> No, and even if we made rdf:XMLLiteral normative that wouldn't change since
> it is optional. Yeah, implementations that claim to recognize rdf:XMLLiteral
> and would accept it would be non-conforming.

Yes, sorry, that’s what I meant to say. With your proposal, conforming implementations that support rdf:XMLLiteral could accept ill-formed XML.

> That's suboptimal but the more
> important point IMO is that two implementations that do recognize
> rdf:XMLLiteral will not be *able* to fully interoperate because the l2v
> mapping is not stable. Do I miss something here?

If both implementations use the informative L2V mapping currently in the spec, then they *are* fully interoperable.

If they do that, the only potential interoperability problem is that [DOM4] *might* change before becoming a W3C Recommendation, thus *possibly* causing a future interoperability issue with later implementations. Given how stable the DOM is, this seems like a rather theoretical possibility. Regardless, W3C procedure clearly prevents us from normatively referencing DOM4 before it hits Rec.

(Interoperability = the ability of two systems to work together. Implementations can interoperate even in total absence of a standard, e.g., by coming from the same vendor or through reverse-engineering. Standards = a tool to promote interoperability. They achieve this by defining what it means for an implementation to conform to the standard. Vendors can then claim that their products conforms, and users can make product choices based on such claims. If the vendor didn’t lie, and the specification writers didn’t screw up (e.g., by inserting too many MAYs and SHOULDs), then all users making that choice will enjoy interoperability.)

>> The DOM4 problem we have is with the value space only. There's no
>> problem with the lexical space. There's every reason to *require*
>> implementations to do the right thing for the lexical space. The
>> lexical space is more critical for interoperability anyways.
> 
> The lexical space of rdf:HTML is "the set of Unicode [UNICODE] strings" and
> thus doesn't add any constraints. Again, do I miss something here?

rdf:XMLLiteral.


Here’s some suggested wording; this should work both for rdf:HTML and for rdf:XMLLiteral:

[[
The lexical space
    is implementation-dependent.
The lexical-to-value mapping
    is Implementation-dependent.

[…]

NOTE
Implementations may use the following approach for the lexical space and lexical-to-value mapping of this datatype. This approach depends on [DOM4], a specification that has not yet reached W3C Recommendation status, and is therefore not normatively required.

[details on lexical space and L2V mapping go here]
END NOTE

]]

This isn’t pretty, but it’s logically consistent and keeps the mess contained to the smallest possible area.

Best,
Richard



> 
> 
> --
> Markus Lanthaler
> @markuslanthaler
> 
> 
> 
>

Received on Tuesday, 17 December 2013 18:40:26 UTC