Thanks for your comment. I have made some additional comments below:
Toby Inkster wrote:
For XMLLiterals which aren't well-formed would it be a good compromise
to say that the literal should still be generated as normal (i.e.
including tags) but just shouldn't be given an rdf:XMLLiteral datatype?
e.g.
<p property="rdfs:comment">Hello<br>World</p>
Generates:
<rdf:Description about="">
<rdfs:comment>Hello<br>World</rdfs:comment>
</rdf:Desciption>
This makes it more consistent with XHTML+RDFa.
Some of us discussed this briefly earlier today. I actually do NOT
believe this makes it consistent with XHTML+RDFa, but I still think it
is something we should consider adding. In XHTML+RDFa that <br> would
be omitted from the output (well, <br/> would be) if it were a plain
literal, and would be included (and potentially annotated with in-scope
xmlns declarations) if it were an XMLLiteral. There is NO mechanism in
XHTML+RDFa to take the complete, unaltered content of a node and make
that the object - encoded or not.
The thing is that what you want at the end of the day is for every
Conforming RDFa Processor to emit the same triples given the same input,
right? So the behavior needs to be predictable. If we made the constraint:
If the object of a triple would be an XMLLiteral, and the input to
the processor is not well-formed [XML
<http://htmlwg.mn.aptest.com/htmlwg/rdfa-html/#ref_XML>], then the
processor MUST transform any reserved characters in the object to
ensure it is well-formed (e.g., transforming '<' to <) The rules
for such a transformation are defined at ... (some spec).
So, in this case, the resulting item would continue to be typed as an
XMLLiteral, and would adhere to the constraints of an XMLLiteral. Would
such a change satisfy your comment? And if so, do you believe such a
constraint should be added to the general processing rules of
RDFaSYNTAX? Or is this unique to HTML4+RDFa?
--
Shane P. McCarron Phone: +1 763 786-8160 x120
Managing Director Fax: +1 763 786-8180
ApTest Minnesota Inet: sh...@aptest.com
