Re: RDFa and Web Directions North 2009

Hi Henri,

>>> It doesn't represent XML attribute spelled "xmlns:foo" in the XML source
>>> code as attributes in the API. Thus, if you write a XOM-based consumer for
>>> RDFa-in-XML as currently defined, you can't just swap the parser to an HTML5
>>> parser and have it work.
>>
>> It appears to me that this could be considered to be either a bug in the
>> HTML5 parser, or in XOM.
>
> Absent RDFa, it clearly isn't a bug in either. RDFa is what adds a problem.

Please see my other email about how this breaks currently working HTML
documents.


>>> currently drafted HTML5 features need the change that exposing
>>> xmlns:foo-based RDFa would require for consistency with the exposure of
>>> xmlns:foo in XML.
>>
>> So is there a precise requirement in HTML5 that mandates how a parser must
>> expose xmlns:foo when producing SAX events, for instance?
>
> No. On the contrary, the parser is explicitly allowed not to expose them.
> But obviously, that solution wouldn't work for RDFa as proposed.
>
> | If the XML API doesn't support attributes in no namespace
> | that are named "xmlns", attributes whose names start with
> | "xmlns:", or attributes in the XMLNS namespace, then the
> | tool may drop such attributes.
> http://www.whatwg.org/specs/web-apps/current-work/#coercing-an-html-dom-into-an-infoset

That section doesn't seem relevant to our discussion. It looks to me
like it relates to what can happen to a DOM that is produced by an
HTML5 parser, as opposed to what can happen to a document on the way
in to an HTML5 parser.

So the comment you quote seems to be saying that a toolset that is
using an XML API that will *consume* an HTML5-generated DOM, can drop
attributes that are ambiguous in relation to XML.

My reading of this would be as follows: say there is a source document
that contains the attribute @abc:def; whilst this attribute should be
'passed through' the HTML5 parser, it would cause problems once it got
out the 'other side' and reached an XML parser, unless the namespace
'abc' was declared. The section you quote allows the toolset to create
a non-namespaced attribute along the lines of 'abcU00003Adef', so as
to avoid invalid XML reaching the XML API.

But I don't read that as implying that the HTML5 parser itself (or any
of the steps bringing information *in* to it) is free to drop this
attribute, or any others, and doing so would break
backwards-compatibility with current browser behaviour.

Note also that in this 'post parsing consumption', if we are just
dealing with examples like @xmlns then there should not be any
problems, since 'xmlns' -- unlike 'abc' in the previous example --
doesn't need to be declared.

So @xmlns should just be 'passed through' the HTML5 parser, and be
ready for processing by the 'XML API' that your quote refers to:

  <div xmlns:dc="http://purl.org/...">
    ...
  </div>

It's much the same as @xml:lang. (The 'xml' namespace also doesn't
need to be declared, either.)

[snip]

Regards,

Mark

-- 
Mark Birbeck, webBackplane

mark.birbeck@webBackplane.com

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)

Received on Wednesday, 18 February 2009 14:09:17 UTC