ISSUE-76: Need feedback on splitting Microdata into separate specification

(bcc: RDFa Developer Community)

ISSUE-76  : http://www.w3.org/html/wg/tracker/issues/76
ACTION-139: http://www.w3.org/html/wg/tracker/actions/139

HTML+RDFa is scheduled to be published as a HTML WG Working Draft
tomorrow. While that addresses most of the concerns for defining RDFa in
HTML for now, two work products remain to be discussed. Those are:

1. The stand-alone HTML5+Microdata draft:

   http://html5.digitalbazaar.com/specs/microdata.html

2. Ensuring that all normative references to RDFa and Microdata are
   removed from the HTML5 specification:

   http://html5.digitalbazaar.com/specs/html5-nosemantics.html

Note that the two drafts above are 45 days old and will have to be
updated before publishing an HTML+Microdata FPWD or an HTML5-NoSemantics
FPWD.

Here are the basic premises and reasoning behind the two drafts listed
above:

* Either RDFa or Microdata (or both) may fail in the marketplace.
* It is more productive for philosophically divergent communities
(RDFa/Microdata) within a larger community (HTML WG) to have their own
work products during a period of active debate. Those complete work
products should only be presented to the larger group for consensus when
they reach maturity.
* Both HTML+RDFa and HTML+Microdata should be allowed to become mature
drafts before consensus on inclusion or dismissal is discussed.
* Having the RDFa and Microdata specification separate from the HTML5
specification will allow those technologies to evolve independently from
HTML5 (after REC).

Possible conclusions:

* If either RDFa or Microdata fail in the marketplace in the long-term,
it would be advisable to allow either (or both) to fail without having a
negative impact on the HTML5 spec proper.
* The HTML+RDFa and HTML+Microdata drafts should be allowed to mature
until Last Call before one or both are selected for inclusion into
HTML5. A productive way to enable that maturation process is to separate
the concerns into separate documents.
* If we don't separate the documents into different work products, the
alternative is to argue over which work product to allow, which does not
lead to the production of a specification outlining each philosophy.
Worse, it may prevent a particular work product from being developed to
maturity before it is struck down.

It is for these reasons that the two specifications listed above (after
they have been updated and revised) should be published as FPWDs.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: The Pirate Bay and Building an Equitable Culture
http://blog.digitalbazaar.com/2009/08/30/equitable-culture/

Received on Wednesday, 14 October 2009 15:45:32 UTC