parseType="Literal"

In the last round of specs we lost something ... between the cracks ...

The previous round had Concepts doing more work with XML Literals.
In the last round I did not discuss the mapping from RDF/XML to an
rdf:XMLLiteral, but Dave pointed to my (non-existent) discussion ... :(

I did have an action to propose text to Dave: I suspect he didn't see the
text which was here (two versions):

http://sealpc09.cnuce.cnr.it/jeremy/RDF-concepts/2002-10-26/rdf-concepts.htm
l#ForDave

(also in the archive)

On reflection, here's yet another vesion, I'll number the paras for
discussion.

In
http://www.w3.org/TR/rdf-syntax-grammar/#parseTypeLiteralPropertyElt
replace the last paragraph with:
[[
[1] The result of a literal l from rdf:parseType="Literal" content is an
implementation dependent XML Literal.

[2] Implementations MAY use the exclusive canonicalization with or without
comments [XC14N] of the literal text l to find the lexical form.

[3] Implementations MAY choose to ignore namespaces that are not visibly
utilized (as defined by [XC14N]), XML comments, and aspects of an XML
document that are not reflected in the canonical form (e.g. insignificant
white space within element tags).

[4] Implementations MAY choose to not ignore such aspects of the literal
text l.

[5] Implementations are NOT REQUIRED to perform canonicalization
when creating an RDF graph corresponding to an RDF/XML document.

[6] Implementations MUST preserve in the lexical form of the XML Literal the
information found in the exclusive canonicalization without comments [XC14N]
of the literal text l.

[7] See the [RDF-CONCEPTS] section on XML Literals for further information.
]]

[1] Constrains implementations a bit.

[2] - [5] are all just (normative) suggestions, to leave implementors with
ideas about how to do this. They are normative in that an implementor will
know that they have satisfied their obligations if they perform [2].

[6] is the only paragraph that defines the minimum requirement, but I think
it could be deleted. This would then, technically, allow an RDF
implementation to always return an empty string.

Given that this is (too?) long; it could be reduced to just say [1] [2] [5]
[7].

The problem is that the phrasing is inevitably daunting, [6] requires some
study of an obscure recommendation to understand it.

Jeremy

Received on Friday, 22 November 2002 12:41:07 UTC