- From: Jeremy Carroll <jjc@hpl.hp.com>
- Date: Fri, 22 Nov 2002 18:40:09 +0100
- To: w3c-rdfcore-wg@w3.org
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