RE: Made rdf:HTML/XMLLiteral non-normative

On Tuesday, December 17, 2013 7:40 PM, Richard Cyganiak wrote:
> Hi Markus,

Hi again :-)


> 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,

OK, I don't think we need to discuss concepts but I just checked all other
documents again to see what would need to be changed

-- RDF 1.1 Semantics --

Only mention: Two other datatypes rdf:XMLLiteral and rdf:HTML are defined in
[RDF11-CONCEPTS]D interpretations MAY fail to recognize these datatypes.

Could simply be dropped

 
-- RDF Schema 1.1 --

Only mentions non-normatively that:

  The class rdf:HTML is the class of HTML literal values. rdf:HTML is an
instance of rdfs:Datatype and a subclass of rdfs:Literal
  The class rdf:XMLLiteral is the class of XML literal values.
rdf:XMLLiteral is an instance of rdfs:Datatype and a subclass of
rdfs:Literal.

No change needed


-- RDF 1.1 XML Syntax --

rdf:HTML not mentioned; rdf:XMLLiteral is obviously used to type
'rdf:parseType="Literal" content'

No change needed here either.


No mentions at all in:
 - RDF 1.1 Turtle
 - RDF 1.1 TriG 
 - RDF 1.1 N-Triples 
 - RDF 1.1 N-Quads 
 - RDF 1.1 Test Cases 
 - JSON-LD 
 - JSON-LD API


> 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.

As far as I can see, there are no normative definitions depending on these.
Since you said this now several times, could you point me to such normative
definitions that depend on these datatypes?


> 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 happen to care a lot about internal consistency, that's why I'd
> really rather not go down the third route.

Me too but I still can't see how this change we cause anything to be
internally inconsistent.


> More on the second option below.
> 
> On 17 Dec 2013, at 16:44, Markus Lanthaler  wrote:
[...]
> >> 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.

With my change, there would be no conformance statement about that feature
because it is non-normative. On the other hand, even according to your
proposal conforming implementations can still accept
"<not>well-formed"^^rdf:XMLLiteral because they don't have to recognize
rdf:XMLLiteral. This *only* changes if they *also* claim to recognize
rdf:XMLLiteral. But that's nitpicking IMO that doesn't buy you much in
practice.


> > 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.

Right, but the same applies to just about everything.


> 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.

The same was said about promises which then required us to go through a
second last call with JSON-LD and finally make the API non-normative.


[...]
> >> 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.
> 
> [.]

Sorry to be sarcastic, by why don't we go the last mile and also add a

  The IRI denoting this datatype
      is implementation-dependent.

while we are already at it?


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

While I agree that it isn't pretty, I obviously disagree with the rest of
that sentence. I think I've spent enough time to explain my opinion and
reasoning. I still believe the right thing to do would be to simply drop the
two statements in section 5.4 and be done with it:

  1. If the IRI http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral
     is recognized then it refers to the datatype rdf:XMLLiteral;
  2. If the IRI http://www.w3.org/1999/02/22-rdf-syntax-ns#HTML is 
     recognized then it refers to the datatype rdf:HTML;


--
Markus Lanthaler
@markuslanthaler

Received on Tuesday, 17 December 2013 19:30:10 UTC