Re: Request to publish HTML+RDFa (draft 3) as FPWD

On Tue, Sep 15, 2009 at 9:36 PM, Manu Sporny <msporny@digitalbazaar.com> wrote:
> The 3rd draft of the HTML+RDFa specification has been released and is
> available here:
>
> http://html5.digitalbazaar.com/specs/rdfa.html
>
> The diff-marked version can be found here:
>
> http://html5.digitalbazaar.com/specs/rdfa-diff-20090906-20090915.html
>
> Changes in this version of the spec include:
>
> * Lots of xmlns: fixes and spec language changes around xmlns:.
> * Explicit references from HTML+RDFa sections to pertinent sections of
>  XHTML+RDFa spec.
> * Explicit language ensuring that RDFa attributes, attribute values,
>  and CURIEs are conforming in HTML5 and XHTML5.
> * Normative pointers to xmlns:-prefixed attribute processing that
>  should be used to create URI mappings in non-XML mode documents.
> * Added editorial warnings about potential changes in xmlns: as
>  the HTML5 document moves toward Last Call and the distributed
>  extensibility issue is addressed.
>
> There are now 2 remaining issues, 6 deferred issues (that should be
> addressed via a separate document, wiki, process), and 30 addressed
> issues. Details on the status/resolution of each issue can be found here:
>
> http://rdfa.info/wiki/html5-rdfa-wd-issues
>
> There have been no issues that have been added to the wiki by reviewers
> or that have been re-opened by reviewers since the last draft was
> published. Discussion related to the second draft didn't produce any
> technical issues, but that doesn't mean there aren't any. If there are
> any new technical issues, they must and will be dealt with during the
> Working Draft phase.
>
> I feel confident that the remaining 2 issues can be addressed and that
> the document is ready for FPWD.

Hi Manu,

I'd like to officially add some concerns about the technical contents
of this draft. I realize some of them are going to be hard to
impossible to address while keeping with the goals of this draft
(which I understand to be "integrate RDFa with HTML5"), however Maciej
asked me to send this nonetheless.

The biggest concern is that I think RDFa, and by extension this draft,
is simply too complex to author documents for, as well as interpret
data from.

For example the CURIE mechanism means that there's a big risk that if
part of a document is copied, it risks loosing its meaning since
prefixes might no longer be declared. It could potentially even change
its meaning if the same prefixes are declared, but declared to a
different value, though this seems less likely to happen. The same
thing could potentially even happen if a Node is moved around in the
DOM.

Another problem is the flexibility of RDFa to express arbitrary graphs
of data. While this might not be a huge problem for someone authoring
a document since you can simply choose not to express complex graphs
someone reading a document with RDFa risks being exposed to it.

I firmly believe that one of the reasons for the success of HTML and
the web is that anyone can simply use the "view source" feature
available in most browsers, see how someone else did something, and
then do the same thing himself/herself.

It's not just the ability to create arbitrary graphs that seems
worrisome, but features like incomplete triplets, that I'm concerned
will make it hard for authors to understand other authors documents.

The complexity argument aside, I'm also not fully understanding the
processing model with regards to xmlns prefixed attributes. Is it
intended that consuming RDFa in HTML documents should be done without
looking at the namespace of attributes? I.e. that DOM Level 1 methods
should be used? I'm asking because HTML5 parsing currently requires
that attributes whose name start with "xmlns:" are parsed into the
null namespace, and with the localName containing the for example
"xmlns:foo". However in an XHTML document, parsing xmlns prefixed
attributes result in attributes in the in the
"http://www.w3.org/2000/xmlns/" namespace with a localName of for
example "foo".

While processing using DOM Level 1 methods is seems doable, it is the
only specification that I know of where that is done. I would imagine
that this will cause problems. For example a javascript implementation
couldn't use the lookupNamespacePrefix function defined in DOM Level 3
and implemented in most commonly used browsers.

Again, I realize that some of these problems might not be possible to
address, but I wanted to let you know my concerns early in the
process.

/ Jonas

Received on Friday, 18 September 2009 03:48:13 UTC