HTML+RDFa Issues (update)

We had a fairly productive discussion last week (draft minutes[1])
regarding the most pressing issues surrounding HTML+RDFa. A brief
summary of the findings can be found here:

http://rdfa.info/wiki/rdfa-in-html-issues#RDFa_Task_Force_Discussion_Order

Regrets for the call tomorrow, I won't have Internet access.

Some quick thoughts on the next set of issues:

== Processing of xmlns:* in non-XML languages ==

I think that we should phase out xmlns:* for the following reasons:

 * There is a case-sensitivity issue when used in HTML4 markup.
 * It's technically feasible, but has led to a number of
   namespace rants and "polluting HTML4/5 with namespaces" rants.

We could replace xmlns:* with @prefix or Mark's upcoming @token
proposal. xmlns:* should exist for backwards compatibility, but we could
suggest that it may be phased out in future versions of RDFa and should
not be used for new markup.

== Case sensitivity for xmlns: attributes and prefixes in attribute
   values ==

As Shane has mentioned previously, we should immediately update the
XHTML+RDFa errata document to say that all prefixes specified by xmlns:
should be lower-case. In other words, authors SHOULD NOT use mixed case
for prefixes. Therefore, doing the following would be frowned upon:

xmlns:Foo or xmlns:FooBar or xmlns:FOOBAR

the suggested markup should be:

xmlns:foo or xmlns:foobar or xmlns:foobar

I agree with Shane's assessment: I don't think we need to change the
parsing rules to lower-case prefix names in xmlns:. We should provide
guidance to authors so that if they want to create markup that works in
both HTML and XHTML, they should not mix case if xmlns: is used.

This point isn't moot if we transition away from using xmlns:* - we will
still need to provide guidance for those that continue to use xmlns:* in
XHTML1.1 documents.

= Use of regular CURIEs in @rel =

I believe that Julian Reschke has raised this issue several times. I
don't remember the technical issue and I remember Ben stating clearly
that there isn't a technical issue.

I don't have any input on this at the present time. Clearly, if a
technical issue exists with CURIEs in @rel - we must address it.

= Script-based modification of DOM =

If we include language to address this issue in an XYZ+RDFa document,
the language should be minimal.

The only time that RDFa enters the picture is when the
(X)HTML/Javascript model/control layer serializes/streams the (X)HTML
document into/to a tree model and hands it off to the RDFa parser. The
RDFa parser shouldn't have any knowledge of how the tree model is
generated - but we shouldn't be strict about making this point.

Re-parsing can be done whenever a DOM changed happens, on a X second
timeout basis, or at the leisure of the browser - for example, when CPU
usage is low.

If this is a question of /when/ the RDFa parser should be called, our
answer should be "whenever the application layer wants to run the RDFa
parser".

If this is a question of /how/ the RDFa parser should be called, we
shouldn't go to great lengths to specify how that is done. For example,
if speed optimizations for incremental DOM parsing of an HTML document
(versus complete parsing of the HTML document) are desired - the
implementation is up to the implementer of the incremental RDFa parser
(which would need specific hooks into the DOM layer and vice versa).

The important part is that the triples that are generated via an
incremental RDFa parser should be exactly the same as if the document
was parsed fully. I don't think we need to specify much more than that.

-- manu

[1] http://www.w3.org/2009/06/25-rdfa-minutes.html

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: Bitmunk 3.1 Released - Browser-based P2P Commerce
http://blog.digitalbazaar.com/2009/06/29/browser-based-p2p-commerce/

Received on Thursday, 2 July 2009 04:01:02 UTC