Philip Taylor wrote:
Manu Sporny wrote:
[...]
[17:37:12] Shane McCarron: we have no option about well formedness of
xml literals. its a requirement
[17:37:18] … not our requirement. RDF
Slightly off-topic: RDF seems to always require canonicalisation
(http://www.w3.org/TR/rdf-concepts/#dfn-rdf-XMLLiteral - "encoding as
UTF-8 yields exclusive Canonical XML (with comments, with empty
InclusiveNamespaces PrefixList)").
http://www.w3.org/2006/07/SWD/RDFa/testsuite/xhtml1-testcases/0011.sparql
seems to ignore that requirement since it allows different ways of
serialising the XML. Is that intentional?
More general comment: How is this different to XMLLiterals in
RDFa-in-XHTML? When you're implementing that, you can't just copy
bytes from the data input stream directly - you at least have to
insert xmlns declarations to ensure the output is
namespace-well-formed. And if the XMLLiteral contains some &entity;
that's defined in the XHTML page's DTD then it will have to be
expanded out so that it's correct once it's separated from the DTD,
and so on. As far as I can see, that's pretty much impossible to
implement unless you parse the whole page with an XML parser and then
use an XML serialisation algorithm on an element sub-tree to get the
XMLLiteral.
It seems logical to me that RDFa-in-HTML should work the same way -
you parse the whole page with an HTML parser and then use exactly the
same XML serialisation algorithm as before.
(I understand that it may be impossible to specify that behaviour if
you're relying on HTML4, since HTML4 doesn't specify how to parse into
a structure that can be serialised as XML; but that's why I'd want to
base it on the HTML5 parsing algorithm instead, which makes this all
quite easy :-) )
[17:36:32] … I think we have two really nasty issues right now: The
first being xmlns + case sensitivity: both of which are fixed if we move
to @prefix and declare that prefix is always case-sensitive (and
implement the legacy case-insensitivity stuff for xmlns that we've been
talking about in the community over the past couple of days).
Related the two issues, a consequence of implementing XMLLiterals
using HTML5's parsing and XML-serialisation algorithms is that content
like:
<div property="..."><span xmlns:foo="..."></span></div>
would fail to generate an XMLLiteral. The 'xmlns:foo' gets parsed into
an attribute with local name "xmlns:foo" in no namespace. That local
name is not an NCName, so it's impossible to serialise as XML, and the
XML serialisation algorithm will fail.
Some possible solutions for this issue:
* Change the HTML5 parsing algorithm so xmlns:foo gets local name
"foo" in the XML Namespaces namespace. (That seems very unlikely to
happen, because of backward-compatibility issues with existing content.)
* Add some ugly hacks in the serialisation process, e.g. find all
attributes named "xmlns:foo" and pretend they were called "foo" in the
XML Namespaces namespace while serialising.
* Don't support XMLLiterals.
Don't support XMLLitererals in HTML, would, I think, be the safest
approach. What is supported with HTML is already a subset of what's
supported in XHTML because of the former's inherent limitations. This
approach wouldn't add a burden that folks aren't already operating under
because they're using HTML.
* Discourage the use of xmlns:foo attributes, and replace them with
@prefix or something.
(In all but the last of those cases, xmlns:foo would still be a
problem for any other tool that attempts to convert HTML to XML (using
HTML5's parsing rules), e.g.
http://services.philip.html5.org/html-to-xhtml/ strips out the
attributes entirely because they can't be represented in XML.)
Folks have to remember that adding a new attribute to handle differences
between HTML and XHTML is probably the more extreme option, and will
lead to confusion, as well as breakage when people use XHTML, but serve
pages up as HTML. Which many, many people do now.
Supporting a subset of RDFa in HTML would, to me, be better than
supporting a different version of RDFa.
Shelley
