- From: Markus Lanthaler <markus.lanthaler@gmx.net>
- Date: Tue, 17 Dec 2013 17:44:07 +0100
- To: "'Richard Cyganiak'" <richard@cyganiak.de>
- Cc: "'RDF Working Group WG'" <public-rdf-wg@w3.org>
On Tuesday, December 17, 2013 4:18 PM, Richard Cyganiak 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. 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? > 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? -- Markus Lanthaler @markuslanthaler
Received on Tuesday, 17 December 2013 16:44:40 UTC