Re: XMLLiteral handling in RDFa in HTML

On Thu, May 28, 2009 at 11:46 AM, Smylers <Smylers@stripey.com> wrote:

> 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.
>

But there's a difference between how HTML5 handles the existing elements in
HTML4, and how it handles ones that don't exist. Forgive me, I know I'm
harping on this one, but @property is not defined in HTML4, but it was
temporarily added to HTML5. That would have impacted on RDFa in HTML
(actually RDFa in XHTML5, too), but HTML5 would still be processing the HTML
defined in the HTML4 document.



>
> 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'm assuming that the addition of DOM methods is equivalent to modifying the
DOM?

http://dev.w3.org/html5/spec/Overview.html#microdata-dom-api

I had thought we were done with hard coding methods for specific elements
with DOM Level 1, but evidently not.



>
> > 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.
>

Really, I didn't know that was an underlying principle behind the work.
That's good to know, thanks.



>
> > 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.
>

I can agree with this. Kind of. If a page is designated as HTML5, then it
can be processed as HTML5 without any breakage to pages still designated as
HTML4. If a specification is external to HTML4, then I'm not sure it needs
to comply with HTML4 limitations.


We're already dealing with new stuff in HTML5, such as MathML and SVG, both
of which cannot be used in HTML4, but hopefully can be used in HTML5. I
wonder if we shouldn't do the same with RDFa?


> > 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.
>


If they wanted to provide input directly, rather than through snide asides,
true.


>
> > 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!)
>

I'm in the HTML WG, and I'm about half way to adopting a view of ignoring
the whole spec.

Just joking.

Really.


>
> > 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.
>

I think we'll have to disagree about how to view this event. But, I'd rather
you were right.


>
> > 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.
>

You have an excellent point. I'll withhold my concerns about redefining
attributes until I see a stable spec. That's not to say I won't have
comments on other sections, outside of my concerns about RDFa.


>
> Smylers
>
>
Shelley