Re: XMLLiteral handling in RDFa in HTML

Shelley Powers writes [but quotes re-ordered to put the technical stuff
before the process stuff]:

> One of the issues that Manu recorded in the RDFa issues wiki page is
> that perhaps we also need to look at how the DOM works. That's not an
> unfair question, and though it doesn't help issues with HTML4, it
> might with HTML5.

Distinguishing between HTML 4 and HTML 5 only makes sense if they are
treated as distinct languages.  The HTML 5 spec defines how to process
all HTML, including HTML written to the HTML 4 spec, and we know that
that's what browsers actually do.

If the compatibility of code running in browsers is important, efforts
to treat HTML 4 and HTML 5 as distinct container languages is unlikely
to be fruitful.

> Since the DOM is being modified, in fact was modified for the new
> microdata section,

Oooh, I missed that -- in what way does the microdata section modify the
Dom?

> I don't think it's outside the realm of possibility of making
> modifications to it in order to work through some of these issues.

The HTML-5-specified munging from an HTML input document to a Dom is
supposed to be only because legacy web content depends on it.  (If any
of it turns out not to be, then it could be removed and everybody wins.)
Given this, any additional language which wishes to hook into HTML as
currently found on the web is going to have to cope with that munging,
as ugly as it may be.

> To be able to seriously consider this, though, we have to at least
> have respect for each others' interests.

Yes, though there is a massive asymmetry in size of existing
deployments.  Unfortunately not breaking existing webpages which rely on
various historical behaviours has got to trump adapting the language to
make things easier for a new feature being added.

> it would have been helpful to have folks who have implemented RDFa
> libraries in JS participating,

Definitely.

> Yes, some of the HTML WG folks are participating,

Well surely "some" is as much as we ever get -- or want?  Having
everybody in the HTML working group state their opinion would likely be
unmanageable.

> but the HTML WG is only half the equation when it comes to HTML5. It
> would seem that the WhatWG folks would rather spend their time making
> fun of the folks participating.

There seem to be at least many people on both mailing lists (I joined
them both at the same time), so I don't think it's possible to so neatly
divide folks into tribes like that.

But clearly anybody who is making fun of those participating is aware of
what's going on, and has the opportunity to give their input if they
want to.  The existence of two separate lists is no worse for this topic
than any other.

> Sure, we can ignore them, but their comments do reflect a lack of
> respect that, I think, undermines what we do. More importantly, it
> makes me doubt that anything the RDFa folks generate isn't going to be
> honored going forward.

That's possible, but since it hasn't happened yet that's going to be
troublesome to get evidence for.  It's probably better to spend time
resolving actual issues, preferably technical ones, than potential ones.

(And probably whatever ends up in HTML 5, there are going to be people
outside the working group who ignore it!)

> And yes, I am going to bring up @property again, as tedious as it is,
> because it is a good demonstration of what happens when the HTML5
> working groups don't have respect for other specification efforts.

It seemed quite the opposite to me:

* property was added by a single author, so it can hardly be a flaw in
  the respect of the working group as a whole.

* property was specified in a way which doesn't currently conflict with
  RDFA, and the e-mail announcing it explained how this was so.  Clearly
  not conflicting was an issue, and efforts were taken to avoid it.

* When feedback was given that it would conflict with proposed future
  changes to RDFA, it was swiftly renamed to avoid the issue.

As such it's a demonstration that feedback is taken into account, and
that avoiding conflicts with other specifications is important.

> Yes, the use of @property was pulled, but the casual nature of its
> inclusion and then its deletion is disquieting.

Surely that's exactly how commit-then-review is supposed to work?  The
editor committed something, the working group reviewed it, and then it
was improved accordingly.

What matters is the content of the final standard, not of intermediate
steps along the way.

Smylers

Received on Thursday, 28 May 2009 16:47:41 UTC