Re: RDFa and Web Directions North 2009

Hi Henri,

>> Could you elaborate what exactly the problem with XOM is? I didn't get it
>> from this paragraph.
>
> 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.
>
> You'd need to change the HTML5 parser to expose attributes spelled
> "xmlns:foo" in the same way XML namespace mapping context is exposed. Such a
> change would be a non-zero change with non-zero cost making the line of
> argument that RDFa using attributes spelled "xmlns:foo" involves zero
> cost/change to HTML5 implementors bogus.

There are two aspects to this debate. Some people want RDFa to be
added to HTML5, and that browsers do something with it. I'd love to
see that too, but then I'd also like to solve world hunger, and teach
the world to sing.

The second aspect of this debate is that, provided the HTML5 spec
doesn't do anything that breaks backwards-compatibility with current
browsers, then we can *already* do clever stuff with RDFa in HTML5. We
don't need anything extra in the specification -- thanks for asking.

Now, if you break backwards-compatibility -- for example, by stripping
out attributes that begin with a certain six character sequence --
then that's obviously going to be a problem.

So it's kind of weird to turn that particular problem back on to those
who want to use RDFa in all future browsers, by saying "this proves
that your argument is bogus".

What you are essentially saying is that "your argument that there is
no work involved in allowing RDFa to be parsed in JavaScript, in
HTML5, is bogus because there _is_ work involved...to undo the way
that we have broken backwards-compatibility".

Mmm...


> Note that the Validator.nu HTML Parser currently exposes a XOM tree, so a
> parser exposing XOM is not a theoretical construct. None of the 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.

You mean the un-change. We're not talking about exposing attributes,
we're talking about not suppressing them.


>>> There's also a technical issue for browsers: For resolving a prefix in a
>>> namespace mapping context on the XML side in a browser, it would make sense
>>> to intern the prefix being queried and then do pointer compares against
>>> interned local names of attributes in the "http://www.w3.org/2000/xmlns/"
>>> namespace as traversing up the tree. If you ever wanted browsers to
>>> implement any RDFa features natively, being sensitive to xmlns:foo
>>> attributes set with setAttribute() would preclude a pointer compare-based
>>> lookup and would require actually inspecting string data unless the internal
>>> data structures of browsers were changed. (But see point #13 in my previous
>>> email on the topic of changing the data structures.)
>>
>> That doesn't seem to be true. An implementation of setAttribute (L1) would
>> just need to know that an attribute named "xmlns:*" is something special,
>> and internally map it.
>
> Well, internally mapping it specially would be a non-zero change/cost on
> browsers making the line of argument that there's no cost or action required
> on behalf of browser vendors bogus.

I think this is incorrect. There is no mapping needed, because an
attribute called "xmlns:dc" is just that; there is nothing special
about it in an HTML document. It could be called "foo-dc", or anything
else. So provided that setAttribute() and getAttribute() cope with
attribute names that contain colons -- and current browsers do -- then
that's it, there is nothing more to do.

Of course, all of this discussion is superseded by the use of @prefix
or @token. However, it is important to clarify that even in the use of
@xmlns, there really is no problem.

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 12:05:19 UTC