Henri's RDFa statements in the XHTML2 FAQ

[Manu Sporny]

Just throwing this out there in case some of you haven't seen it yet:

http://hsivonen.iki.fi/xhtml2-html5-q-and-a/

In it, Henri makes the following assertions:

> What happens to RDFa?
>     RDFa (in XHTML but not in HTML!) is a W3C Recommendation and, as
> such, doesn’t need any terminating action per the W3C Process. It’s
> unclear if another WG will develop further RDFa specs.

We will be developing further RDFa specs - whether it happens inside the
W3C or outside the W3C is still up in the air.

> Do semantics round-trip in an HTML5 to XHTML5 to HTML5 conversion?
>    Yes, provided that the first HTML5 input is valid and you don’t
> ascribe semantics to characters that aren’t allowed in XML (such as
> form feed or U+FFFF). Note that RDFa isn’t valid in either HTML5 or
> XHTML5 as currently drafted.

We are certainly addressing all of the issues raised during the past
several months[1]. Henri failed to mention that this work continues and
that we are making progress.

> What about XHTML5 to HTML5 to XHTML5?
>    Not if namespace-based extensibility is used. However, in the
> common case, the conversion chain does round trip if the input is
> valid XHTML5 + SVG 1.1 + MathML 2.0 (this excludes RDFa), doesn’t use
> namespaces from outside those specs (It’s debatable if the previous
> condition already covers this.), xml:space on HTML elements is not
> considered to affect semantics and relative URLs are rewritten so that
> xml:base attributes can be removed without breaking links. (Answer
> clarified/corrected 2009-07-07.)

My understanding is that XHTML5 and SVG 1.1 contain namespace support -
so why is RDFa excluded from those languages on the basis of using
namespaces and CURIEs in attributes (other than Henri's personal
preferences)?

> Are the semantics of HTML5 extensible?
>    Yes. With microdata.

It's difficult to believe that WHATWG doesn't have a bias (as Ian has
asserted repeatedly) when Microdata is being proposed as a solution.
Microdata clearly does not have a test suite, does not have a set of
implementations, and does not have much in the way of implementation
feedback. RDFa has all of those in spades, but gets absolutely no
mention as an alternative approach.

Henri's "FAQ" attempts to assert that RDFa is, and will continue to be,
an incompatible technology with HTML5 and XHTML5. This couldn't be
further from the truth. There will be an HTML+RDFa specification and
there will be implementations (and, yes, that includes HTML5 and
XHTML5). Whether WHATWG chooses to include it in their standard is what
Henri is asserting as not happening. On that point, only time will
tell... however, RDFa is out there in the wild now and it works. We'll
ensure that it works in HTML5/XHTML5 as well.

-- manu

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

--
Manu Sporny
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/

[rubys]

Manu Sporny wrote:

> Just throwing this out there in case some of you haven't seen it yet:
>
> http://hsivonen.iki.fi/xhtml2-html5-q-and-a/
>
> In it, Henri makes the following assertions:
>
>> What happens to RDFa?
>>     RDFa (in XHTML but not in HTML!) is a W3C Recommendation and, as
>> such, doesn’t need any terminating action per the W3C Process. It’s
>> unclear if another WG will develop further RDFa specs.
>
> We will be developing further RDFa specs - whether it happens inside the
> W3C or outside the W3C is still up in the air.

I hope that this work can be done inside of the W3C.  If there is
anything I can do to help, let me know.

>> Do semantics round-trip in an HTML5 to XHTML5 to HTML5 conversion?
>>    Yes, provided that the first HTML5 input is valid and you don’t
>> ascribe semantics to characters that aren’t allowed in XML (such as
>> form feed or U+FFFF). Note that RDFa isn’t valid in either HTML5 or
>> XHTML5 as currently drafted.
>
> We are certainly addressing all of the issues raised during the past
> several months[1]. Henri failed to mention that this work continues and
> that we are making progress.

I look forward to the time when this work results in a draft
specification for RDFa in HTML.  I will note that the W3C Process
Document states "Consensus is not a prerequisite for approval to
publish; the Working Group MAY request publication of a Working Draft
even if it is unstable and does not meet all Working Group requirements.".

I will also note that Henri's assertion about RDFa not being valid also
applies to ARIA, despite the fact that his conformance checker has
recognized ARIA for quite some time.

>> What about XHTML5 to HTML5 to XHTML5?
>>    Not if namespace-based extensibility is used. However, in the
>> common case, the conversion chain does round trip if the input is
>> valid XHTML5 + SVG 1.1 + MathML 2.0 (this excludes RDFa), doesn’t use
>> namespaces from outside those specs (It’s debatable if the previous
>> condition already covers this.), xml:space on HTML elements is not
>> considered to affect semantics and relative URLs are rewritten so that
>> xml:base attributes can be removed without breaking links. (Answer
>> clarified/corrected 2009-07-07.)
>
> My understanding is that XHTML5 and SVG 1.1 contain namespace support -
> so why is RDFa excluded from those languages on the basis of using
> namespaces and CURIEs in attributes (other than Henri's personal
> preferences)?

The current HTML5 draft special cases the SVG and MathML namespaces.

>> Are the semantics of HTML5 extensible?
>>    Yes. With microdata.
>
> It's difficult to believe that WHATWG doesn't have a bias (as Ian has
> asserted repeatedly) when Microdata is being proposed as a solution.
> Microdata clearly does not have a test suite, does not have a set of
> implementations, and does not have much in the way of implementation
> feedback. RDFa has all of those in spades, but gets absolutely no
> mention as an alternative approach.
>
> Henri's "FAQ" attempts to assert that RDFa is, and will continue to be,
> an incompatible technology with HTML5 and XHTML5. This couldn't be
> further from the truth. There will be an HTML+RDFa specification and
> there will be implementations (and, yes, that includes HTML5 and
> XHTML5). Whether WHATWG chooses to include it in their standard is what
> Henri is asserting as not happening. On that point, only time will
> tell... however, RDFa is out there in the wild now and it works. We'll
> ensure that it works in HTML5/XHTML5 as well.

What is currently in the HTML 5 draft has not yet been found to enjoy
consensus.  I encourage people to work with the editor to get changes
that they feel necessary made to this draft.  As an alternative, I
encourage people to produce drafts, possibly including as much or as
little of the current draft and submit them for consideration.

If you need access to the cvs repository for the HTML Working Group,
please contact Mike Smith for access, and provide him with your ssh key.
  It is my understanding that Rob Sayre and Steve Faulkner have already
done so.

> -- manu
>
> [1]http://rdfa.info/wiki/rdfa-in-html-issues#RDFa_Task_Force_Discussion_Order

- Sam Ruby

[Ben Adida-2]

Sam Ruby wrote:
> The current HTML5 draft special cases the SVG and MathML namespaces.

And the HTML5 folks are complaining about the RDFa design? :)

> What is currently in the HTML 5 draft has not yet been found to enjoy
> consensus.  I encourage people to work with the editor to get changes
> that they feel necessary made to this draft.

To date, Ian's approach has been far from that of an impartial editor
with whom such differences can be worked out. Manu tried, really hard,
for a long time, at which point Ian dreamed up microdata. Let's stop
pretending that this is a viable path.

> As an alternative, I encourage people to produce drafts, possibly including as much or as
> little of the current draft and submit them for consideration.

Maybe that's a more viable option. Is this how the HTML WG intends to
receive contributions from other w3c groups, by forking the spec?

-Ben

[rubys]

Ben Adida wrote:
> Sam Ruby wrote:
>> The current HTML5 draft special cases the SVG and MathML namespaces.
>
> And the HTML5 folks are complaining about the RDFa design? :)

:-)

>> What is currently in the HTML 5 draft has not yet been found to enjoy
>> consensus.  I encourage people to work with the editor to get changes
>> that they feel necessary made to this draft.
>
> To date, Ian's approach has been far from that of an impartial editor
> with whom such differences can be worked out. Manu tried, really hard,
> for a long time, at which point Ian dreamed up microdata. Let's stop
> pretending that this is a viable path.

Fair enough.

>> As an alternative, I encourage people to produce drafts, possibly including as much or as
>> little of the current draft and submit them for consideration.
>
> Maybe that's a more viable option. Is this how the HTML WG intends to
> receive contributions from other w3c groups, by forking the spec?

With only one quibble that is of no consequence, the answer is yes.

http://lists.w3.org/Archives/Public/www-archive/2009Jun/0132.html

The quibble: I believe that in order to produce a draft with the intent
of being considered a product of the HTML Working Group, one must be a
member of that group.  Fortunately, we the Working Group has a policy of
being open to all that wish to contribute, so effectively this is not a
barrier at all.

> -Ben

- Sam Ruby

[Michael(tm) Smith-4]

Sam Ruby <rubys@...>, 2009-07-07 13:34 -0400:

>  If you need access to the cvs repository for the HTML Working Group,

Note: That repository is /sources/public/html5 on our public CVS server.

> please contact Mike Smith for access,

Note to anybody who already has write access to our public CVS server
(a.k.a. dev.w3.org) -- for example, if you're maintaining docs there
already as drafts for another working group -- You don't need to send me
a key, because you already have write access to the whole server.

So if you have access already and want to check in something there, all
you need to do is give me a heads-up that you'll be checking in (so I'm
not blindsided by seeing a commit come in from out of blue).

And please do not check files into the top-level /html5 directory, but
instead create a new subdirectory under that -- e.g., /html5/FOO --
where FOO is whatever you want to name it (you don't have to ask for an
OK about what to name it, just pick a name, and we can rename it later
if we want to for some reason).

> and provide him with your ssh key.

So if you don't have access already, here are a few more details about
what's needed as far as the key:

You need to have an SSH2 keypair -- SSH2, not SSH1. SSH2 is what
ssh-keygen and other tools have generated by default for a long time
time. And it can be either RSA or DSA -- it doesn't matter which.

If you have a keypair you generated way back when, note that it might be
an SSH1 key, in which case you'll need to generate a new, SSH2 keypair.

As far as how to generate a keypair, if you're on Mac OSX or Linux, you
can do it just by running the "ssh-keygen" command with no arguments,
and just hitting Enter at the prompts to accept the defaults -- e.g.,
not setting a password on the key (unless you really want to deal with
typing in a password when you need to actually use the key).

After you've generated the keypair, you need to send me the public-key
part of the keypair. Please don't send me the private-key part, and
please especially don't send the private key to me attached as a reply
with a mailing list CC'ed (yeah, that has actually happened). The public
key is the one that'll have a ".pub" extension on its filename -- probably
"id_rsa.pub" (if you've used the ssh-keygen defaults) or "id_dsa.pub".

There are some general how-to details on keypair generation here:

  http://github.com/guides/providing-your-ssh-key

...including some details on how to generate keys on Windows machines
using the "PuTTYGen" GUI application.

If you have questions or need help, please feel free to e-mail me directly.

> It is my understanding that Rob Sayre and Steve Faulkner have
> already done so.

That's correct.

  --Mike

--
Michael(tm) Smith
http://people.w3.org/mike/

[Michael(tm) Smith-4]

Sam Ruby <rubys@...>, 2009-07-07 20:34 -0400:

>  The quibble: I believe that in order to produce a draft with the intent of
>  being considered a product of the HTML Working Group, one must be a member
>  of that group.  Fortunately, we the Working Group has a policy of being open
>  to all that wish to contribute, so effectively this is not a barrier at all.

That is also my understanding of the publication policy that the chairs
of the group have been seeking to establish: Anybody can join the group,
and anybody in the group can become an editor, and any substantial draft
that a member of the group takes time to put together and commits to
further editing for (including responding to comments on) deserves
support from the group for consideration of publication as a FPWD -- in
parallel with any other drafts published by the group.

I realize that's a different approach than the way most other groups
handle FPWD publication. But there is a somewhat exceptional history
behind the chartering of this particular group at the W3C, and the
circumstances that let up to that, and the set of circumstances that to
some degree the group inherited when it was chartered. And those
circumstances may mean that we all need to consider taking some
different approaches in the near term (for example, genuinely
encouraging and supporting parallel publication and review of multiple/
alternative WDs) in order to be successful with this work overall in the
long term.

I believe we have leadership in the group with the resolve that would be
needed to manage that kind of approach and make it ultimately
successful. If we have additional editors with the resolve to put other
drafts for discussion and to really carry through on them in the process
toward wider publication, I believe you will find we have organizational
commitment and ability to make that actually happen.

  --Mike

--
Michael(tm) Smith
http://people.w3.org/mike/

[Michael(tm) Smith-4]

"Michael(tm) Smith" <mike@...>, 2009-07-08 12:54 +0900:

> Sam Ruby <rubys@...>, 2009-07-07 13:34 -0400:
>
> >  If you need access to the cvs repository for the HTML Working Group,
>
> Note: That repository is /sources/public/html5 on our public CVS server.

Some reasons why it would be worth taking time to check in drafts
there and manage them there instead of elsewhere:

We have shared facilities set up there already for things like automatically
sending notifications of checkins to an archived mailing list --
http://lists.w3.org/Archives/Public/public-html-commits/ 

And along with, we have a mechanism for generating diff-marked HTML
copies (that is, with color-coded change highlighting) for new versions
of editor's drafts), with notifications of those going to yet another
list -- http://lists.w3.org/Archives/Public/public-html-diffs/ (my
mechanism for actually generating those is currently turned off because
I need to make some fixes to it, but I can say that if we get some more
editors contributing, it will motivate me to fix that).

And along with those mailing lists, I have some simple stuff set up that
causes checkin notifications to be echoed to the #html-wg IRC channel,
as well as to http://twitter.com/html5

My point in mentioning those things is that if you have a draft that you
contribute as an editor, those are all mechanisms that would give your
draft visibility as an actual contribution to the work of the group, and
to put it on the same footing as an editor's draft being managed by any
other member in the group.

As far as what happens next beyond just having something in that
repository as an editor's draft, see my previous message:

  http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Jul/0018.html

  --Mike

--
Michael(tm) Smith
http://people.w3.org/mike/

[Manu Sporny]

Sam Ruby wrote:
> Manu Sporny wrote:
>> We will be developing further RDFa specs - whether it happens inside the
>> W3C or outside the W3C is still up in the air.
>
> I hope that this work can be done inside of the W3C.  If there is
> anything I can do to help, let me know.

I believe that almost everyone in this community hopes that the work on
RDFa can be done inside of the W3C. The latest XHTML2 announcement has,
unsurprisingly, made those involved in work related to XHTML2 a bit jumpy.

One of the responsibilities of the RDFa Task Force is to ensure the
long-term viability of RDFa. If long-term viability can only be achieved
outside of the W3C, then so be it.

We are far removed from that possibility now, but we were saying the
same thing about XHTML2 several months ago. Life is full of surprises. :)

I have yet to speak with the Task Force about this proposal, but think
that it fits with the consensus at the moment. Here is what you, Chris
Wilson, Mike Smith, Doug Schepers, Dan Connolly, Philippe, TimBL (and
the rest of W3C) can do:

*Publicly* support an RDFa Interest Group (IG) that operates
/independently/ of SVGWG, HTMLWG, and WHATWG. The RDFa IG should advise
each group on the implementation of RDFa in each language, perhaps even
writing (or helping to write) the draft language to be
included/referenced in each spec.

Since RDFa can be applied to a variety of languages, the work undertaken
by the IG does not wholly belong in the HTML WG, the WHAT WG, nor was it
going to belong to XHTML2 for much longer. Since the majority of the
work is already done, it also does not need the W3C resources associated
with a full WG.

If RDFa is going to continue to flourish, the technical work should be
insulated to a large degree from the political flotsam and jetsam left
in the wake of W3C, XHTML2, HTML5, and WHATWG. Every day spent
attempting to figure out how to navigate the W3C Policy waters, lately -
an increasing part of this Task Force's time, is time lost on RDFa.

So, if you would like to help - help us ensure that there is an RDFa IG
that operates independently of each one of these contentious groups.
State it publicly, and push the rest of W3C management that may be
sitting on the fence to make it happen... and make it happen publicly.

> Ben Adida wrote:
>> Sam Ruby wrote:
>> What is currently in the HTML 5 draft has not yet been found to enjoy
>> consensus.  I encourage people to work with the editor to get changes
>> that they feel necessary made to this draft.
>
> To date, Ian's approach has been far from that of an impartial editor
> with whom such differences can be worked out. Manu tried, really hard,
> for a long time, at which point Ian dreamed up microdata. Let's stop
> pretending that this is a viable path.

To clarify my personal intentions, I will continue to push on WHATWG for
HTML5+RDFa. I started doing it because there was hope in convincing
WHATWG to adopt RDFa in a slightly modified form. That hope has been all
but extinguished over the past 7 months. Now I find myself doing it
because I'm a standards masochist. It's the Doug Schepers vs. Microsoft
 (include native SVG in IE, dammit!) school of thought (and suffering).
I'm starting to enjoy the repeated rejection. :)

-- manu

--
Manu Sporny
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/

[Ralph R. Swick]

At 10:58 AM 7/8/2009 -0400, Manu Sporny wrote:
>I believe that almost everyone in this community hopes that the work on
>RDFa can be done inside of the W3C.

And I'm  part of that community :)

...

>I have yet to speak with the Task Force about this proposal, but think
>that it fits with the consensus at the moment. Here is what you, Chris
>Wilson, Mike Smith, Doug Schepers, Dan Connolly, Philippe, TimBL (and
>the rest of W3C) can do:
>
>*Publicly* support an RDFa Interest Group (IG) that operates
>/independently/ of SVGWG, HTMLWG, and WHATWG. The RDFa IG should advise
>each group on the implementation of RDFa in each language, perhaps even
>writing (or helping to write) the draft language to be
>included/referenced in each spec.

That makes a lot of sense to me.  There are multiple roles a W3C
Interest Group can play.  Advising on the deployment, both on the
Web and in other "host" languages, is well within charter.  An
IG can certainly be given a deliverable to offer proposals for
RDFa in other host languages and other Groups can be given
a chartered dependency to coordinate with an IG.  Ultimately
the W3C Recommendation document must still come from a
Working Group.  Such a document could draw freely from
Interest Group Notes, however.

And I particularly think it's useful to have a group who fills the
role of coordinator as different host languages present partially
overlapping needs for alterations as RDFa is adapted to each
host language.  The Semantic Web community is in the best
position to know which features are crucial to the architecture
and which features are design choices that could be implemented
in other ways for other host languages with little impact on
the utility of RDFa.

...
>To clarify my personal intentions, I will continue to push on WHATWG for
>HTML5+RDFa. I started doing it because there was hope in convincing
>WHATWG to adopt RDFa in a slightly modified form. That hope has been all
>but extinguished over the past 7 months.

I'm hoping you will find the strength to carry on a bit longer
so the community can find some reinforcement.

-Ralph

[rubys]

Manu Sporny wrote:

> Sam Ruby wrote:
>> Manu Sporny wrote:
>>> We will be developing further RDFa specs - whether it happens inside the
>>> W3C or outside the W3C is still up in the air.
>> I hope that this work can be done inside of the W3C.  If there is
>> anything I can do to help, let me know.
>
> I believe that almost everyone in this community hopes that the work on
> RDFa can be done inside of the W3C. The latest XHTML2 announcement has,
> unsurprisingly, made those involved in work related to XHTML2 a bit jumpy.
>
> One of the responsibilities of the RDFa Task Force is to ensure the
> long-term viability of RDFa. If long-term viability can only be achieved
> outside of the W3C, then so be it.
>
> We are far removed from that possibility now, but we were saying the
> same thing about XHTML2 several months ago. Life is full of surprises. :)
>
> I have yet to speak with the Task Force about this proposal, but think
> that it fits with the consensus at the moment. Here is what you, Chris
> Wilson, Mike Smith, Doug Schepers, Dan Connolly, Philippe, TimBL (and
> the rest of W3C) can do:
>
> *Publicly* support an RDFa Interest Group (IG) that operates
> /independently/ of SVGWG, HTMLWG, and WHATWG. The RDFa IG should advise
> each group on the implementation of RDFa in each language, perhaps even
> writing (or helping to write) the draft language to be
> included/referenced in each spec.
>
> Since RDFa can be applied to a variety of languages, the work undertaken
> by the IG does not wholly belong in the HTML WG, the WHAT WG, nor was it
> going to belong to XHTML2 for much longer. Since the majority of the
> work is already done, it also does not need the W3C resources associated
> with a full WG.
>
> If RDFa is going to continue to flourish, the technical work should be
> insulated to a large degree from the political flotsam and jetsam left
> in the wake of W3C, XHTML2, HTML5, and WHATWG. Every day spent
> attempting to figure out how to navigate the W3C Policy waters, lately -
> an increasing part of this Task Force's time, is time lost on RDFa.
>
> So, if you would like to help - help us ensure that there is an RDFa IG
> that operates independently of each one of these contentious groups.
> State it publicly, and push the rest of W3C management that may be
> sitting on the fence to make it happen... and make it happen publicly.

Before I agree, let me give my perspective.  People are going to use
RDFa in HTML, and as such I feel that such usage should be documented,
test suites set up, and libraries made to interoperate, yadda, yadda,
yadda.  I don't happen to agree that that work as largely done.

The word that troubles me most in the above is "perhaps".  If you see an
IG as potentially one that exclusively gives "advice", then frankly I
don't see that as a path to success.  And if such is entirely separate
from the HTML WG, then /perhaps/ (<grin>) I'll check in from time to
time and make comments, but I will be perfectly honest: this activity
won't have my full attention.

Talking specifically about a "RDFa in HTML" draft, I don't see how
anybody can take a position that microdata is in scope for the HTML WG
and RDFa in HTML is not.  As such, if there is interest in working on
such a document, then I will do my part to enable those who wish to do
so have direct access to CVS, etc.

If that is the intent instead, then I fully support that work.  If there
is enough overlap between the people doing the work for HTML and those
doing the work for SVG that it makes sense to formally recognize this as
an IG so that a separate mailing list can be set up for coordination,
then I think that's a dandy idea.

>> Ben Adida wrote:
>>> Sam Ruby wrote:
>>> What is currently in the HTML 5 draft has not yet been found to enjoy
>>> consensus.  I encourage people to work with the editor to get changes
>>> that they feel necessary made to this draft.
>> To date, Ian's approach has been far from that of an impartial editor
>> with whom such differences can be worked out. Manu tried, really hard,
>> for a long time, at which point Ian dreamed up microdata. Let's stop
>> pretending that this is a viable path.
>
> To clarify my personal intentions, I will continue to push on WHATWG for
> HTML5+RDFa. I started doing it because there was hope in convincing
> WHATWG to adopt RDFa in a slightly modified form. That hope has been all
> but extinguished over the past 7 months. Now I find myself doing it
> because I'm a standards masochist. It's the Doug Schepers vs. Microsoft
>  (include native SVG in IE, dammit!) school of thought (and suffering).
> I'm starting to enjoy the repeated rejection. :)

You are welcome to work with the WHATWG, but there is no requirement
that you do so.  I gather that Ben would rather work directly with the
HTML WG.  That's OK too.

> -- manu

- Sam Ruby

[Henri Sivonen]

> Just throwing this out there in case some of you haven't seen it yet:
>
> http://hsivonen.iki.fi/xhtml2-html5-q-and-a/
>
> In it, Henri makes the following assertions:
>
> > What happens to RDFa?
> >     RDFa (in XHTML but not in HTML!) is a W3C Recommendation and, as
> > such, doesn’t need any terminating action per the W3C Process. It’s
> > unclear if another WG will develop further RDFa specs.
>
> We will be developing further RDFa specs - whether it happens inside  
> the
> W3C or outside the W3C is still up in the air.

Interesting. I hadn't considered the WHATWGish going outside the W3C  
option for RDFa. I think "unclear" is fair given "still up in the air".

> > Do semantics round-trip in an HTML5 to XHTML5 to HTML5 conversion?
> >    Yes, provided that the first HTML5 input is valid and you don’t
> > ascribe semantics to characters that aren’t allowed in XML (such as
> > form feed or U+FFFF). Note that RDFa isn’t valid in either HTML5 or
> > XHTML5 as currently drafted.
>
> We are certainly addressing all of the issues raised during the past
> several months[1]. Henri failed to mention that this work continues  
> and
> that we are making progress.

I included "as currently drafted" to avoid suggesting it can't change.

> > What about XHTML5 to HTML5 to XHTML5?
> >    Not if namespace-based extensibility is used. However, in the
> > common case, the conversion chain does round trip if the input is
> > valid XHTML5 + SVG 1.1 + MathML 2.0 (this excludes RDFa), doesn’t  
> use
> > namespaces from outside those specs (It’s debatable if the previous
> > condition already covers this.), xml:space on HTML elements is not
> > considered to affect semantics and relative URLs are rewritten so  
> that
> > xml:base attributes can be removed without breaking links. (Answer
> > clarified/corrected 2009-07-07.)
>
> My understanding is that XHTML5 and SVG 1.1 contain namespace  
> support -
> so why is RDFa excluded from those languages on the basis of using
> namespaces and CURIEs in attributes (other than Henri's personal
> preferences)?

Oh please. The "personal preferences" line again.

XHTML5 doesn't currently make the RDFa attributes valid on HTML  
elements. Even if it did, you can't round trip via HTML5, because  
namespace declarations aren't serializable as HTML5 and RDFa isn't  
defined for HTML (in the present tense).

> > Are the semantics of HTML5 extensible?
> >    Yes. With microdata.
>
> It's difficult to believe that WHATWG doesn't have a bias (as Ian has
> asserted repeatedly) when Microdata is being proposed as a solution.
> Microdata clearly does not have a test suite, does not have a set of
> implementations, and does not have much in the way of implementation
> feedback. RDFa has all of those in spades, but gets absolutely no
> mention as an alternative approach.

Rightly or wrongly, it's not an approach supported by the HTML 5 spec  
today (or the day before yesterday). Note that I didn't mention  
microformats, either, even though those are allowed as currently  
drafted.

> Henri's "FAQ" attempts to assert that RDFa is, and will continue to  
> be,
> an incompatible technology with HTML5 and XHTML5.

That's an unfair claim. My blog post only asserts things about RDFa in  
round-tripping in the present tense.

--
Henri Sivonen
hsivonen@...
http://hsivonen.iki.fi/

[Edward O'Connor]

Hi Sam,

You encouraged the RDFa-in-HTML effort to take place under the HTML WG:

> Before I agree, let me give my perspective. People are going to use
> RDFa in HTML, and as such I feel that such usage should be documented,
> test suites set up, and libraries made to interoperate, yadda, yadda,
> yadda.
[...]
> If you see an IG as potentially one that exclusively gives
> "advice"[...]and if such is entirely separate from the HTML WG[...
> such] activity won't have my full attention.
>
> Talking specifically about a "RDFa in HTML" draft, I don't see how
> anybody can take a position that microdata is in scope for the HTML WG
> and RDFa in HTML is not. As such, if there is interest in working on
> such a document, then I will do my part to enable those who wish to do
> so have direct access to CVS, etc.

(Personally, I agree that the HTML WG is a sensible home for any
RDFa-in-HTML spec effort.)

But you went on to say to Manu that he is "welcome to work with the
WHATWG, but there is no requirement that you do so."

That's strictly speaking true, assuming the RDFa-in-HTML effort remains
outside the purview of the HMTL WG but, were the WG to take on the
RDFa-in-HTML effort, working with the WHATWG would be required. Our
charter requires us to "actively pursue convergence with WHATWG[...]"

Just trying to make sure Manu et al. are aware of this charter
requirement, for when deciding how/where to proceed with their work.


--
Edward O'Connor

[Ben Adida-2]

Sam Ruby wrote:
> Before I agree, let me give my perspective.  People are going to use
> RDFa in HTML, and as such I feel that such usage should be documented,
> test suites set up, and libraries made to interoperate, yadda, yadda,
> yadda.  I don't happen to agree that that work as largely done.

I agree that this should be done. It's not done yet, but it's well on
its way (and the work on RDFa in XHTML1.1 is of course a huge help in this.)

> Talking specifically about a "RDFa in HTML" draft, I don't see how
> anybody can take a position that microdata is in scope for the HTML WG
> and RDFa in HTML is not.

Well, Henri did just that in his blog post, and Ian clearly thinks that.
 Therein lies the problem. We want to work on RDFa and address real use
cases without being dependent on Ian. Sure, joint work can happen to
enable RDFa in HTML5, but since HTML5 is willing to ignore what Google,
Yahoo, CC, the UK government, and many others are doing, then *some*
group needs to take on that work. That's the point of the RDFa IG.

-Ben

[Shelley Powers]

Ben Adida wrote:

> Sam Ruby wrote:
>  
>> Before I agree, let me give my perspective.  People are going to use
>> RDFa in HTML, and as such I feel that such usage should be documented,
>> test suites set up, and libraries made to interoperate, yadda, yadda,
>> yadda.  I don't happen to agree that that work as largely done.
>>    
>
> I agree that this should be done. It's not done yet, but it's well on
> its way (and the work on RDFa in XHTML1.1 is of course a huge help in this.)
>
>  
>> Talking specifically about a "RDFa in HTML" draft, I don't see how
>> anybody can take a position that microdata is in scope for the HTML WG
>> and RDFa in HTML is not.
>>    
>
> Well, Henri did just that in his blog post, and Ian clearly thinks that.
>  Therein lies the problem. We want to work on RDFa and address real use
> cases without being dependent on Ian. Sure, joint work can happen to
> enable RDFa in HTML5, but since HTML5 is willing to ignore what Google,
> Yahoo, CC, the UK government, and many others are doing, then *some*
> group needs to take on that work. That's the point of the RDFa IG.
>
> -Ben
>
>
>  

I hope you all don't mind me butting into this discussion.

I doubt that the microdata section will live to see final publication,
but I don't see whether it will or won't will impact on whether RDFa is
incorporated into HTML 5.

Just giving my two cents worth, but I can't help thinking a separate
group focused on providing a RDFa in HTML 5 document would ultimately be
the better course anyway.  The problem is that the conformance language
of HTML 5 is such that even if you work through some of the technical
issues, using RDFa within HTML 5 (either served as XML or not) will not
be "conformant".

So perhaps what's really needed is a three prong approach: work on a
separate spec/doc about RDFa in HTML 5, work to get the microdata
section removed from HTML 5 (should happen regardless of RDFa), and work
to eliminate the "not defined here therefore it's non-conformant"
language from the HTML 5 specification.


Shelley

[Ian Hickson]

On Wed, 8 Jul 2009, Ben Adida wrote:
> >
> > Talking specifically about a "RDFa in HTML" draft, I don't see how
> > anybody can take a position that microdata is in scope for the HTML WG
> > and RDFa in HTML is not.
>
> Well, Henri did just that in his blog post, and Ian clearly thinks that.

It isn't microdata or RDFa that are in scope for HTML, it's the use cases
that they solve. I agree that there are use cases that both RDFa and
microdata address that are in scope for HTML, so insofar as that goes,
RDFa and microdata are both in scope for HTML. It's just that RDFa, as
designed, has problems that IMHO must be resolved before it would be
appropriate for HTML; microdata is basically RDFa with those problems
resolved. (Naturally, in designing microdata, other design features that
may have been the result of requirements for RDFa were not addressed; for
example, microdata doesn't support giving types to values. I designed
microdata based on the use cases that were provided, and nothing else.)


> Therein lies the problem. We want to work on RDFa and address real use
> cases without being dependent on Ian.

Which use cases does microdata not address? (There are lots of use cases
that were put forward as reasons for RDFa that RDFa doesn't address, e.g.
it doesn't hook into the drag-and-drop model to support dragging contact
information from an (X)HTML page to an OS address book program.)

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[Ben Adida-2]

Ian Hickson wrote:
>> Therein lies the problem. We want to work on RDFa and address real use
>> cases without being dependent on Ian.
>
> Which use cases does microdata not address?

The problems with microdata have been addressed before by others, I'm
not going to spend the time going into them yet again.

But let's stop this pretense that there are two proposals of equal value
on the table.

While RDFa was getting adoption and traction, you pulled microdata out
of thin air, with no community development, because of some dubious
claims regarding RDFa (claims that, as we're showing progressively, are
very easily addressed). Meanwhile, RDFa has been deployed by Yahoo,
Google, the UK government, Creative Commons, the US government,
Slideshare, and many more.

It's time to standardize what a number of players clearly already want.

-Ben

[Doug Schepers-3]

Hi, Manu-

Manu Sporny wrote (on 7/8/09 10:58 AM):

> Sam Ruby wrote:
>>  Manu Sporny wrote:
>>>  We will be developing further RDFa specs - whether it happens inside the
>>>  W3C or outside the W3C is still up in the air.
>>
>>  I hope that this work can be done inside of the W3C.  If there is
>>  anything I can do to help, let me know.
>
> I believe that almost everyone in this community hopes that the work on
> RDFa can be done inside of the W3C. The latest XHTML2 announcement has,
> unsurprisingly, made those involved in work related to XHTML2 a bit jumpy.

Understandably so.  We did take pains to make

> One of the responsibilities of the RDFa Task Force is to ensure the
> long-term viability of RDFa. If long-term viability can only be achieved
> outside of the W3C, then so be it.
>
> We are far removed from that possibility now, but we were saying the
> same thing about XHTML2 several months ago. Life is full of surprises. :)
>
> I have yet to speak with the Task Force about this proposal, but think
> that it fits with the consensus at the moment. Here is what you, Chris
> Wilson, Mike Smith, Doug Schepers, Dan Connolly, Philippe, TimBL (and
> the rest of W3C) can do:
>
> *Publicly* support an RDFa Interest Group (IG) that operates
> /independently/ of SVGWG, HTMLWG, and WHATWG. The RDFa IG should advise
> each group on the implementation of RDFa in each language, perhaps even
> writing (or helping to write) the draft language to be
> included/referenced in each spec.

I would personally support the continuation of RDFa support and
development, whether that be in a dedicated IG, or as part of another
Working Group.  The SVG WG has reached out to the RDF/a community in the
past and corrected our spec accordingly, and would welcome any further
guidance that is offered from that community.

The SVG WG explicitly added several attributes to SVG Tiny 1.2 to enable
the use of RDFa or Microformats (we are agnostic as to which one is
used); we encourage the use of metadata and semantic extensions to SVG
(including ARIA).  If the metadata community wants to help us refine
that, or even better, come up with tutorials, tests, and other materials
that help people to use those features meaningfully, we would appreciate
the contributions.

It may be that either SVG or RDFa needs to change in order to get the
best results for the wide variety of use cases, but that's the nature of
spec development.


> Since RDFa can be applied to a variety of languages, the work undertaken
> by the IG does not wholly belong in the HTML WG, the WHAT WG, nor was it
> going to belong to XHTML2 for much longer. Since the majority of the
> work is already done, it also does not need the W3C resources associated
> with a full WG.

I'm not much concerned where the work gets done... we could normative
reference work easily from the HTML WG or wherever the work gets done.
If this can be done without Team resources (already stretched thin), so
much the better.

> If RDFa is going to continue to flourish, the technical work should be
> insulated to a large degree from the political flotsam and jetsam left
> in the wake of W3C, XHTML2, HTML5, and WHATWG. Every day spent
> attempting to figure out how to navigate the W3C Policy waters, lately -
> an increasing part of this Task Force's time, is time lost on RDFa.
>
> So, if you would like to help - help us ensure that there is an RDFa IG
> that operates independently of each one of these contentious groups.
> State it publicly, and push the rest of W3C management that may be
> sitting on the fence to make it happen... and make it happen publicly.

If you think it needs to happen in an IG, I would support that and urge
others to as well, with the proviso that you will need to work directly
with implementers to make sure all your bases are covered and the end
result is suitable.


> To clarify my personal intentions, I will continue to push on WHATWG for
> HTML5+RDFa. I started doing it because there was hope in convincing
> WHATWG to adopt RDFa in a slightly modified form. That hope has been all
> but extinguished over the past 7 months. Now I find myself doing it
> because I'm a standards masochist. It's the Doug Schepers vs. Microsoft
>   (include native SVG in IE, dammit!) school of thought (and suffering).
> I'm starting to enjoy the repeated rejection. :)

There's no "versus" there.  I'm working *with* Microsoft to enable them
to reach the inevitable conclusion that they need to support SVG
natively, though active encouragement and gentle reminders. :)

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

[Doug Schepers-3]

Hi, Manu-

Doug Schepers wrote (on 7/8/09 10:33 PM):

> Hi, Manu-
>
> Manu Sporny wrote (on 7/8/09 10:58 AM):
>> Sam Ruby wrote:
>>> Manu Sporny wrote:
>>>> We will be developing further RDFa specs - whether it happens inside
>>>> the
>>>> W3C or outside the W3C is still up in the air.
>>>
>>> I hope that this work can be done inside of the W3C. If there is
>>> anything I can do to help, let me know.
>>
>> I believe that almost everyone in this community hopes that the work on
>> RDFa can be done inside of the W3C. The latest XHTML2 announcement has,
>> unsurprisingly, made those involved in work related to XHTML2 a bit
>> jumpy.
>
> Understandably so. We did take pains to make

Sigh...

Understandably so. We did take pains to make people aware that we are
still invested in RDFa and XHTML, though the FAQ, but there has still
been a lot of confusion and uncertainty.  We expect that the XHTML2 WG
will help tie up those loose ends over the course of their remaining
chartered period.

I agree that the RDFa story needs to be clarified as soon as is possible.


Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

[Ian Hickson]

On Wed, 8 Jul 2009, Ben Adida wrote:
> Ian Hickson wrote:
> >> Therein lies the problem. We want to work on RDFa and address real
> >> use cases without being dependent on Ian.
> >
> > Which use cases does microdata not address?
>
> The problems with microdata have been addressed before by others, I'm
> not going to spend the time going into them yet again.

I'm not aware of any use cases that microdata doesn't handle. There have
been issues raised, but none are use cases that aren't addressed. Since
you claimed the problem was to do with addressing "real use cases", if
there really are some, I would be very grateful if you could elaborate on
what they are.


> But let's stop this pretense that there are two proposals of equal value
> on the table.

I don't claim that; I think microdata has more value. :-) If I didn't, I
wouldn't have introduced it.


> While RDFa was getting adoption and traction, you pulled microdata out
> of thin air, with no community development, because of some dubious
> claims regarding RDFa (claims that, as we're showing progressively, are
> very easily addressed).

I don't think it's fair to dismiss a year's worth of community involvement
as being nothing.

Nor do I think it's fair to cast the concerns that have been raised
regarding RDFa as dubious, and nor am I aware of any serious effort to
actually fix all the problems, only some of the more eggregious ones like
the use of xmlns="". For example, I'm not aware of any plans to remove the
prefix mechanism from RDFa altogether, or replace the URI-based identifier
mechanism with something more friendly.


> Meanwhile, RDFa has been deployed by Yahoo, Google, the UK government,
> Creative Commons, the US government, Slideshare, and many more.

RDFa has existed for much longer than microdata (FPWD in 2007, if I'm not
mistaken), so one would expect it to have greater deployment. The
microdata proposal has existed for barely a quarter, and hasn't ever even
been published in a W3C draft.


> It's time to standardize what a number of players clearly already want.

A number of the players I've spoken to, including some that you list, have
told me they do not actually _want_ RDFa, they just used it because it was
the only option they had at their disposal.

However, if I'm wrong about this, and they really do want RDFa, then the
microdata proposal will die on its own merits and it will eventually be
removed from HTML5, just as we've removed many other features in the past.

Personally I'm not overly interested in the use cases for RDFa and
microdata; I wrote the microdata part of the spec because there was demand
for something to address those use cases and the people I spoke to about
this reported significant issues with the leading solutions in that space,
Microformats and RDFa. So I don't really care all that much if microdata
is ultimately successful as a standard or if RDFa gets more adoption or if
some third solution is found to be better than either. I'm just doing what
I can to address use cases for HTML5, in the same manner as I've
approached every other part of the spec, adopting existing ideas and
solutions where possible, adapting them if necessary, and inventing new
stuff otherwise, all while trying to follow a design philosophy of
backwards compatibility, comprehensive and unambiguous conformance
requirements, simple language design that tries to address the main use
cases but not the edge cases, and so on.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[Julian Reschke]

Ian Hickson wrote:
> ...
> Nor do I think it's fair to cast the concerns that have been raised
> regarding RDFa as dubious, and nor am I aware of any serious effort to
> actually fix all the problems, only some of the more eggregious ones like
> the use of xmlns="". For example, I'm not aware of any plans to remove the
> prefix mechanism from RDFa altogether, or replace the URI-based identifier
> mechanism with something more friendly.
> ...

That may be because there's absolutely no agreement that these aspects
*are* problematic.

BR, Julian