WHATWG Wiki - User contributions [en]

User:Dean

2012-08-18T12:15:02Z

Dean: Created page with 'Dean Edridge'

Dean Edridge

XHTML2 versus HTML5

2009-01-25T09:39:03Z

Dean: ...whereas <code>xml:id</code> can only be used in XML documents.

http://www.w3.org/MarkUp/2009/ED-xhtml-modularization2-20090123/

This is not about HTML versus XHTML, instead this page is an attempt to find out where XHTML2 and HTML5 features overlap, why certain design decisions in HTML5 have been made different, and why HTML5 lacks certain features XHTML2 has.

It is not an attempt to demonstrate that 5 > 2. We know that.

It is also very simple at this point. I wish my time was infinite.

== XHTML Document Module ==

=== The html element ===

XHTML2 has version="" and xsi:schemaLocation="". HTML5 has neither.

'''Rationale:''' HTML5 does away with versioning in HTML defining it equivalent to CSS in that regard. XXX add something ''nice'' about why we do not have xsi:schemaLocation=""

=== The head element ===

XHTML2 has profile="". HTML5 has not.

'''Rationale:''' it does not appear to be used in the wild.

'''Note:''' this is still being debated by the HTML WG.

== XHTML Structural Module ==

=== The blockcode element ===

HTML5 does not have this element. In HTML5 you can use <pre><code> instead.

'''Rationale:''' the blockcode element is not backwards compatible.

=== The heading elements ===

HTML5 does not have the h element. In HTML5 the h1-h6 elements work together with the section element. In XHTML2 only the h element works with the section element.

'''Rationale:''' the h element is not backwards compatible. Also, it seems important to define interaction between the h1-h6 elements and the section element so authors can more easily reuse existing content and assistive technology can still make sense of invalid pages.

=== The separator element ===

HTML5 does not have the separator element. It does have the hr element which means and does the same thing.

'''Rationale:''' the separator element is not backwards compatible and we cannot do away with the hr element so adding an equivalent element would just make matters more complex.

== XHTML Text Module ==

=== The abbr element ===

XHTML2 has a full attribute that can reference another element which provides the expansion (within the same page). HTML5 does not. HTML5 does this implicitly by comparing element contents.

'''Rationale:''' Less work for authors.

=== The l element ===

XXX The XHTML2 open issues list says that the br element will be added back. Does this element stay though?

== XHTML Hypertext Module ==

XXX This module talks about adding the access element to the head element, but the link is broken.

== XHTML List Module ==

HTML5 does not have a a caption element to annotate list items.

'''Rationale:''' XXX

=== The dl, di, dt and dd elements ===

HTML5 does not have the di element. (HTML5 is much clearer in defining this, by the way.)

'''Rationale:''' the di element solves a styling problem.

=== The nl element ===

HTML5 does not have the nl element.

'''Rationale:''' XXX

== XHTML Core Attributes Module ==

=== The xml:id attribute ===

HTML5 does not have this attribute, however, <code>xml:id</code> can be used in XHTML5 web pages.

'''Rationale:''' there already is an id attribute that works fine and can be used both in HTML and XHTML web pages whereas <code>xml:id</code> can only be used in XML documents.

=== The layout attribute ===

HTML5 does not have this attribute.

'''Rationale:''' the pre element can be used instead.

== XHTML Hypertext Attributes Module ==

...

XHTML2 versus HTML5

2009-01-25T09:35:27Z

Dean: however, xml:id can be used in XHTML5 web pages

http://www.w3.org/MarkUp/2009/ED-xhtml-modularization2-20090123/

This is not about HTML versus XHTML, instead this page is an attempt to find out where XHTML2 and HTML5 features overlap, why certain design decisions in HTML5 have been made different, and why HTML5 lacks certain features XHTML2 has.

It is not an attempt to demonstrate that 5 > 2. We know that.

It is also very simple at this point. I wish my time was infinite.

== XHTML Document Module ==

=== The html element ===

XHTML2 has version="" and xsi:schemaLocation="". HTML5 has neither.

'''Rationale:''' HTML5 does away with versioning in HTML defining it equivalent to CSS in that regard. XXX add something ''nice'' about why we do not have xsi:schemaLocation=""

=== The head element ===

XHTML2 has profile="". HTML5 has not.

'''Rationale:''' it does not appear to be used in the wild.

'''Note:''' this is still being debated by the HTML WG.

== XHTML Structural Module ==

=== The blockcode element ===

HTML5 does not have this element. In HTML5 you can use <pre><code> instead.

'''Rationale:''' the blockcode element is not backwards compatible.

=== The heading elements ===

HTML5 does not have the h element. In HTML5 the h1-h6 elements work together with the section element. In XHTML2 only the h element works with the section element.

'''Rationale:''' the h element is not backwards compatible. Also, it seems important to define interaction between the h1-h6 elements and the section element so authors can more easily reuse existing content and assistive technology can still make sense of invalid pages.

=== The separator element ===

HTML5 does not have the separator element. It does have the hr element which means and does the same thing.

'''Rationale:''' the separator element is not backwards compatible and we cannot do away with the hr element so adding an equivalent element would just make matters more complex.

== XHTML Text Module ==

=== The abbr element ===

XHTML2 has a full attribute that can reference another element which provides the expansion (within the same page). HTML5 does not. HTML5 does this implicitly by comparing element contents.

'''Rationale:''' Less work for authors.

=== The l element ===

XXX The XHTML2 open issues list says that the br element will be added back. Does this element stay though?

== XHTML Hypertext Module ==

XXX This module talks about adding the access element to the head element, but the link is broken.

== XHTML List Module ==

HTML5 does not have a a caption element to annotate list items.

'''Rationale:''' XXX

=== The dl, di, dt and dd elements ===

HTML5 does not have the di element. (HTML5 is much clearer in defining this, by the way.)

'''Rationale:''' the di element solves a styling problem.

=== The nl element ===

HTML5 does not have the nl element.

'''Rationale:''' XXX

== XHTML Core Attributes Module ==

=== The xml:id attribute ===

HTML5 does not have this attribute, however, xml:id can be used in XHTML5 web pages

'''Rationale:''' there already is an id attribute that works fine and can be used both in HTML and XHTML web pages.

=== The layout attribute ===

HTML5 does not have this attribute.

'''Rationale:''' the pre element can be used instead.

== XHTML Hypertext Attributes Module ==

...

XHTML2 versus HTML5

2009-01-24T13:57:38Z

Dean: removed my last edit and merged ideas into the first sentence that anne wrote

http://www.w3.org/MarkUp/2009/ED-xhtml-modularization2-20090123/

This is not a HTML vs XHTML article, instead this page is an attempt to find out where XHTML2 and HTML5 features overlap, why certain design decisions in HTML5 have been made different, and why HTML5 lacks certain features XHTML2 has.

It is not an attempt to demonstrate that 5 > 2. We know that (we are just waiting for the W3C to admit it).

It is also very simple at this point. I wish my time was infinite.

== XHTML Document Module ==

=== The html element ===

XHTML2 has version="" and xsi:schemaLocation="". HTML5 has neither.

'''Rationale:''' HTML5 does away with versioning in HTML defining it equivalent to CSS in that regard. XXX add something ''nice'' about why we do not have xsi:schemaLocation=""

=== The head element ===

XHTML2 has profile="". HTML5 has not.

'''Rationale:''' it does not appear to be used in the wild.

'''Note:''' this is still being debated by the HTML WG.

== XHTML Structural Module ==

=== The blockcode element ===

HTML5 does not have this element. In HTML5 you can use <pre><code> instead.

'''Rationale:''' the blockcode element is not backwards compatible.

=== The heading elements ===

HTML5 does not have the h element. In HTML5 the h1-h6 elements work together with the section element. In XHTML2 only the h element works with the section element.

'''Rationale:''' the h element is not backwards compatible. Also, it seems important to define interaction between the h1-h6 elements and the section element so authors can more easily reuse existing content and assistive technology can still make sense of invalid pages.

=== The separator element ===

HTML5 does not have the separator element. It does have the hr element which means and does the same thing.

'''Rationale:''' the separator element is not backwards compatible and we cannot do away with the hr element so adding an equivalent element would just make matters more complex.

== XHTML Text Module ==

=== The abbr element ===

XHTML2 has a full attribute that can reference another element which provides the expansion (within the same page). HTML5 does not. HTML5 does this implicitly by comparing element contents.

'''Rationale:''' Less work for authors.

=== The l element ===

XXX The XHTML2 open issues list says that the br element will be added back. Does this element stay though?

== XHTML Hypertext Module ==

XXX This module talks about adding the access element to the head element, but the link is broken.

== XHTML List Module ==

HTML5 does not have a a caption element to annotate list items.

'''Rationale:''' XXX

=== The dl, di, dt and dd elements ===

HTML5 does not have the di element. (HTML5 is much clearer in defining this, by the way.)

'''Rationale:''' the di element solves a styling problem.

=== The nl element ===

HTML5 does not have the nl element.

'''Rationale:''' XXX

== XHTML Core Attributes Module ==

=== The xml:id attribute ===

HTML5 does not have this attribute.

'''Rationale:''' there already is an id attribute that works fine.

=== The layout attribute ===

HTML5 does not have this attribute.

'''Rationale:''' the pre element can be used instead.

== XHTML Hypertext Attributes Module ==

...

XHTML2 versus HTML5

2009-01-24T13:49:44Z

Dean: added: This article is not about HTML vs XHTML...

http://www.w3.org/MarkUp/2009/ED-xhtml-modularization2-20090123/

This page is an attempt to find out where XHTML2 and HTML5 features overlap, why certain design decisions in HTML5 have been made different, and why HTML5 lacks certain features XHTML2 has.

It is not an attempt to demonstrate that 5 > 2. We know that (we are just waiting for the W3C to admit it).

This article is not about HTML vs XHTML, it is about comparing the proposed features of XHTML2 to the features of (X)HTML5.

It is also very simple at this point. I wish my time was infinite.

== XHTML Document Module ==

=== The html element ===

XHTML2 has version="" and xsi:schemaLocation="". HTML5 has neither.

'''Rationale:''' HTML5 does away with versioning in HTML defining it equivalent to CSS in that regard. XXX add something ''nice'' about why we do not have xsi:schemaLocation=""

=== The head element ===

XHTML2 has profile="". HTML5 has not.

'''Rationale:''' it does not appear to be used in the wild.

'''Note:''' this is still being debated by the HTML WG.

== XHTML Structural Module ==

=== The blockcode element ===

HTML5 does not have this element. In HTML5 you can use <pre><code> instead.

'''Rationale:''' the blockcode element is not backwards compatible.

=== The heading elements ===

HTML5 does not have the h element. In HTML5 the h1-h6 elements work together with the section element. In XHTML2 only the h element works with the section element.

'''Rationale:''' the h element is not backwards compatible. Also, it seems important to define interaction between the h1-h6 elements and the section element so authors can more easily reuse existing content and assistive technology can still make sense of invalid pages.

=== The separator element ===

HTML5 does not have the separator element. It does have the hr element which means and does the same thing.

'''Rationale:''' the separator element is not backwards compatible and we cannot do away with the hr element so adding an equivalent element would just make matters more complex.

== XHTML Text Module ==

=== The abbr element ===

XHTML2 has a full attribute that can reference another element which provides the expansion (within the same page). HTML5 does not. HTML5 does this implicitly by comparing element contents.

'''Rationale:''' Less work for authors.

=== The l element ===

XXX The XHTML2 open issues list says that the br element will be added back. Does this element stay though?

== XHTML Hypertext Module ==

XXX This module talks about adding the access element to the head element, but the link is broken.

== XHTML List Module ==

HTML5 does not have a a caption element to annotate list items.

'''Rationale:''' XXX

=== The dl, di, dt and dd elements ===

HTML5 does not have the di element. (HTML5 is much clearer in defining this, by the way.)

'''Rationale:''' the di element solves a styling problem.

=== The nl element ===

HTML5 does not have the nl element.

'''Rationale:''' XXX

== XHTML Core Attributes Module ==

=== The xml:id attribute ===

HTML5 does not have this attribute.

'''Rationale:''' there already is an id attribute that works fine.

=== The layout attribute ===

HTML5 does not have this attribute.

'''Rationale:''' the pre element can be used instead.

== XHTML Hypertext Attributes Module ==

...

XHTML2 versus HTML5

2009-01-24T13:43:07Z

Dean: a cheeky reminder about web politics

http://www.w3.org/MarkUp/2009/ED-xhtml-modularization2-20090123/

This page is an attempt to find out where XHTML2 and HTML5 features overlap, why certain design decisions in HTML5 have been made different, and why HTML5 lacks certain features XHTML2 has.

It is not an attempt to demonstrate that 5 > 2. We know that (we are just waiting for the W3C to admit it).

It is also very simple at this point. I wish my time was infinite.

== XHTML Document Module ==

=== The html element ===

XHTML2 has version="" and xsi:schemaLocation="". HTML5 has neither.

'''Rationale:''' HTML5 does away with versioning in HTML defining it equivalent to CSS in that regard. XXX add something ''nice'' about why we do not have xsi:schemaLocation=""

=== The head element ===

XHTML2 has profile="". HTML5 has not.

'''Rationale:''' it does not appear to be used in the wild.

'''Note:''' this is still being debated by the HTML WG.

== XHTML Structural Module ==

=== The blockcode element ===

HTML5 does not have this element. In HTML5 you can use <pre><code> instead.

'''Rationale:''' the blockcode element is not backwards compatible.

=== The heading elements ===

HTML5 does not have the h element. In HTML5 the h1-h6 elements work together with the section element. In XHTML2 only the h element works with the section element.

'''Rationale:''' the h element is not backwards compatible. Also, it seems important to define interaction between the h1-h6 elements and the section element so authors can more easily reuse existing content and assistive technology can still make sense of invalid pages.

=== The separator element ===

HTML5 does not have the separator element. It does have the hr element which means and does the same thing.

'''Rationale:''' the separator element is not backwards compatible and we cannot do away with the hr element so adding an equivalent element would just make matters more complex.

== XHTML Text Module ==

=== The abbr element ===

XHTML2 has a full attribute that can reference another element which provides the expansion (within the same page). HTML5 does not. HTML5 does this implicitly by comparing element contents.

'''Rationale:''' Less work for authors.

=== The l element ===

XXX The XHTML2 open issues list says that the br element will be added back. Does this element stay though?

== XHTML Hypertext Module ==

XXX This module talks about adding the access element to the head element, but the link is broken.

== XHTML List Module ==

HTML5 does not have a a caption element to annotate list items.

'''Rationale:''' XXX

=== The dl, di, dt and dd elements ===

HTML5 does not have the di element. (HTML5 is much clearer in defining this, by the way.)

'''Rationale:''' the di element solves a styling problem.

=== The nl element ===

HTML5 does not have the nl element.

'''Rationale:''' XXX

== XHTML Core Attributes Module ==

=== The xml:id attribute ===

HTML5 does not have this attribute.

'''Rationale:''' there already is an id attribute that works fine.

=== The layout attribute ===

HTML5 does not have this attribute.

'''Rationale:''' the pre element can be used instead.

== XHTML Hypertext Attributes Module ==

...

Generic Metadata Mechanisms

2008-09-23T15:03:00Z

Dean: /* DOM consistency */

There have been some requests for introducing generic metadata mechanisms into HTML5.

To help determine what we would need to add, and whether it is worth adding anything, we have to come to an understanding of what the goals and requirements are of such a proposal.

Please document arguments with links to supporting research or links to other wiki pages detailing the anecdotal evidence for or against particular aspects of the goals and requirements.

= Goals =

== What is the problem we are trying to solve? ==

'''Nobody has yet answered this in this wiki; please see http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-September/016186.html for commentary and advice on how to fill this in.'''

== Who faces this problem? ==

Currently a few groups. In the future metadata may become necessary for the average "web consumer" (human or machine) to sort actual information from presentation and structural cruft. In other words, a useful tool for determining the meaning, terms of use, quality and/or authority of a piece of data inside (X)HTML.

'''This section needs to be much, much more detailed. Who exactly faces the problem we're trying to solve? Name names of communities, organizations, companies, etc; show how they are "suffering" today and how they are currently working around the problem.'''

= Requirements: If we assume that we are going to address this need, what do we need to provide? =

Please demonstrate the reasoning behind each requirement, along with examples of how the requirements could be addressed.

== Machine-readable ==

A machine-readable and standardized way to apply semantic properties (metadata) to DOM elements in HTML5 and XHTML5.

'''Needs more detail. What does it mean to be machine-readable?'''

== Disambiguation ==

These properties are capable of being disambiguated between multiple definitions of the property name.

== Finding or defining meaning ==

We should be able to find or define an "authoritative" meaning for an abstract concept like "title" (eg. book title, job title, person's title, land deed, etc...).

'''Needs more detail. What does it mean to "find" an authoritative meaning?'''

== Machine-usability ==

The metadata could be read by UA's and other tools to perform actions that would not be possible without "knowing" what type of thing, quantity, unit or quality an element represents.

'''Needs more detail. How can this work? What does it mean in practice?'''

== DOM consistency ==

The DOM has to be consistent between the HTML and XHTML representations of the HTML5 specification. If it isn't, then migrating between the two becomes non-trivial, especially for scripting.

== Ease of deployment ==

The syntax has to be something that Web authors can easily deploy. If authors can't deploy this, then it won't get critical mass and won't matter.

One could argue that tools will be used to deploy this, that it'll mostly be used by big sites like Facebook, and that thus individual authors don't matter, but this kind of argument ("the tools will save us") has been repeatedly shown to not work, because in practice the tools have to be hand-authored too, and so the complexity is just moved to other people.

== Inlinability ==

It has to have a way to include it inline, so that it is quicker for non-professional developers to use and adopt. Also, putting metadata in the same location as content could prevent errors in updates or copying.

== Abstractability ==

It has to have both a way to abstract it from the HTML, like JS or CSS.

'''Needs more detail. Why does it need to be abstractable?'''

== Sustainability ==

Where possible the proposal should be resistant to temporary or permanent unavailability of an authoritative source (ie, vocabulary provider). This could be achieved, for example, through a P2P or DNS-like mechanism, or by not relying on external sources (e.g. in the way that SSL certificates are checked).

Not doing this would lead to failures during temporary outages or overloading of an authoritative source of metadata definitions, and may make it more resistant to hostile takeover or shutdown of authority.

Distributing an authoritative source needs not make it less authoritative.

== Reuse ==

The proposal should allow metadata and authoritative sources to be reused across elements, pages and sites, because web developers are more likely to use something that does not require repetitively typing the same data.

'''Needs more detail. Reuse how?'''

== Multilingual and Multicultural ==

Not all concepts can be expressed properly in English. A proposal should allow metadata for foreign languages and concepts.

== Authority and Security ==

Since a potential use of metadata appears to be enabling future features of UAs and other tools it follows that this opens the end-user to additional risks. For example, could a page author or hijacker feed a virus to a tool by falsely claiming it to be another type of data; could harm be caused when a metadata authority is hijacked by a group to deliberately mislead or blackmail; could metadata be used for unintended purposes such as spying on or annoying users.

With these risks in mind should there be standard mechanisms for securing metadata and verifying its source (such as signing certificates, encryption or white/black lists).

= Related Proposals, Research and Discussions =

* [http://www.mail-archive.com/whatwg@lists.whatwg.org/index.html#11037 WHATWG Discussions]
* [http://www.w3.org/2001/sw/interest/ w3c Semantic Web Interest Group (SWIG)]
* [http://lists.w3.org/Archives/Public/semantic-web/ W3C SWIG Mailing List Archive]
* [http://microformats.org/wiki/grddl GRRDL (Transformations of XHTML to RDF)]
* [http://www.xanthir.com/rdfa-vs-crdf.php RDFa vs. CRDF (Cascading RDF Proposal)]
* [http://research.talis.com/2005/erdf/wiki Embedded RDF Wiki]
* [http://research.talis.com/2005/erdf/wiki/Main/RdfInHtml RDF in HTML (Embedded RDF Examples)]
* [http://en.wikipedia.org/wiki/Semantic_web Wikipedia page on Semantic Web]
* [http://microformats.org/wiki/what-are-microformats What are Microformats? (microformats.org)]
* [http://www.foaf-project.org/ Friend of a Friend Project (FOAF)]
* [http://dublincore.org/ Dublin Core Metadata Initiative (DCMI)]

= Pre-Existing Software Systems That Demonstrate A Need =

* [http://www.kaply.com/weblog/operator/ Operator] - A semantic web processor for extracting metadata from all forms of HTML embedded by using Microformats and RDFa.
* [http://rdfa.digitalbazaar.com/fuzzbot/ Fuzzbot] - A semantic web processor for extracting triples from HTML4 and XHTML1.0, 1.1 and 2.0 data sources.
* [http://simile.mit.edu/wiki/Longwell Longwell] - Longwell is a web-based RDF-powered highly-configurable faceted browser.
* [http://simile.mit.edu/wiki/Piggy_Bank Piggy Bank] - Piggy Bank is a Firefox extension that turns your browser into a mashup platform, by allowing you to extract data from different web sites and mix them together. Piggy Bank also allows you to store this extracted information locally for you to search later and to exchange at need the collected information with others.
* [http://simile.mit.edu/wiki/Solvent Solvent] - Solvent is a Firefox extension that helps you write screen scrapers for Piggy Bank.
* [http://simile.mit.edu/wiki/Semantic_Bank Semantic Bank] - Semantic Bank is the server companion of Piggy Bank that lets you persist, share and publish data collected by individuals, groups or communities.
* [http://simile.mit.edu/wiki/Crowbar Crowbar] - Crowbar is a web scraping environment based on the use of a server-side headless mozilla-based browser. Its purpose is to allow running javascript scrapers against a DOM to automate web sites scraping but avoiding all the syntax normalization issues.
* [http://simile.mit.edu/wiki/Referee Referee] - Referee is a program that reads your web server logs and crawls your referrers (the links that point to your pages) and extract metadata from those pages and text around the links that pointed to your pages.

== Proposals ==

=== Inline (as multiple attributes) ===

Multiple new metadata attributes such as in RDFa.

* Pro: Reasonably simple to add to spec.

* Con: Dependent on changes to HTML spec for future changes to metadata spec.
* Con: Would probably require a different syntax for block or external version of same metadata (makes it hard to move).
* Con: Requires documentation and standardization in the HTML spec rather than through a separate document and standards body.
* Con: More potential for attribute name collisions with future HTML attributes.
* Con: Appears to make metadata reuse difficult.

=== Inline (in a single attribute) ===

One metadata attribute with complex content (such as the style attribute)

* Pro: New properties can be added without changing the HTML spec.
* Pro: Changing properties does not affect the DOM.
* Pro: The properties are grouped together.
* Pro: Requirements very similar to style="" and onclick="".

* Con: Requires new metadata format to be created.
* Con: Makes it harder to select individual property/value pairs through CSS or DOM scripting. (Might require dedicated APIs... Ugh.)

=== Block or external metadata ===

Metadata is defined elsewhere from element and targeted in the manner of CSS or Javascript.

* Pro: Does not clutter the HTML.
* Pro: Gives it more space to develop such as style did once it was abstracted from HTML.
* Pro: May be easier to import, export, reuse, sign and translate.
* Pro: May be applied to elements that the author cannot change attributes on (eg, dynamic, protected or generated content).
* Pro: Speed up where external metadata can be cached.

* Con: Requires new metadata format to be created.
* Con: CSS-like targeting or use of class or id to apply metadata adds complexity/indirection.

Generic Metadata Mechanisms

2008-09-23T14:59:42Z

Dean: /* Machine-readable */

There have been some requests for introducing generic metadata mechanisms into HTML5.

To help determine what we would need to add, and whether it is worth adding anything, we have to come to an understanding of what the goals and requirements are of such a proposal.

Please document arguments with links to supporting research or links to other wiki pages detailing the anecdotal evidence for or against particular aspects of the goals and requirements.

= Goals =

== What is the problem we are trying to solve? ==

'''Nobody has yet answered this in this wiki; please see http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-September/016186.html for commentary and advice on how to fill this in.'''

== Who faces this problem? ==

Currently a few groups. In the future metadata may become necessary for the average "web consumer" (human or machine) to sort actual information from presentation and structural cruft. In other words, a useful tool for determining the meaning, terms of use, quality and/or authority of a piece of data inside (X)HTML.

'''This section needs to be much, much more detailed. Who exactly faces the problem we're trying to solve? Name names of communities, organizations, companies, etc; show how they are "suffering" today and how they are currently working around the problem.'''

= Requirements: If we assume that we are going to address this need, what do we need to provide? =

Please demonstrate the reasoning behind each requirement, along with examples of how the requirements could be addressed.

== Machine-readable ==

A machine-readable and standardized way to apply semantic properties (metadata) to DOM elements in HTML5 and XHTML5.

'''Needs more detail. What does it mean to be machine-readable?'''

== Disambiguation ==

These properties are capable of being disambiguated between multiple definitions of the property name.

== Finding or defining meaning ==

We should be able to find or define an "authoritative" meaning for an abstract concept like "title" (eg. book title, job title, person's title, land deed, etc...).

'''Needs more detail. What does it mean to "find" an authoritative meaning?'''

== Machine-usability ==

The metadata could be read by UA's and other tools to perform actions that would not be possible without "knowing" what type of thing, quantity, unit or quality an element represents.

'''Needs more detail. How can this work? What does it mean in practice?'''

== DOM consistency ==

The DOM has to be consistent between HTML and XHTML representations. If it isn't, then migrating between the two becomes non-trivial, especially for scripting.

== Ease of deployment ==

The syntax has to be something that Web authors can easily deploy. If authors can't deploy this, then it won't get critical mass and won't matter.

One could argue that tools will be used to deploy this, that it'll mostly be used by big sites like Facebook, and that thus individual authors don't matter, but this kind of argument ("the tools will save us") has been repeatedly shown to not work, because in practice the tools have to be hand-authored too, and so the complexity is just moved to other people.

== Inlinability ==

It has to have a way to include it inline, so that it is quicker for non-professional developers to use and adopt. Also, putting metadata in the same location as content could prevent errors in updates or copying.

== Abstractability ==

It has to have both a way to abstract it from the HTML, like JS or CSS.

'''Needs more detail. Why does it need to be abstractable?'''

== Sustainability ==

Where possible the proposal should be resistant to temporary or permanent unavailability of an authoritative source (ie, vocabulary provider). This could be achieved, for example, through a P2P or DNS-like mechanism, or by not relying on external sources (e.g. in the way that SSL certificates are checked).

Not doing this would lead to failures during temporary outages or overloading of an authoritative source of metadata definitions, and may make it more resistant to hostile takeover or shutdown of authority.

Distributing an authoritative source needs not make it less authoritative.

== Reuse ==

The proposal should allow metadata and authoritative sources to be reused across elements, pages and sites, because web developers are more likely to use something that does not require repetitively typing the same data.

'''Needs more detail. Reuse how?'''

== Multilingual and Multicultural ==

Not all concepts can be expressed properly in English. A proposal should allow metadata for foreign languages and concepts.

== Authority and Security ==

Since a potential use of metadata appears to be enabling future features of UAs and other tools it follows that this opens the end-user to additional risks. For example, could a page author or hijacker feed a virus to a tool by falsely claiming it to be another type of data; could harm be caused when a metadata authority is hijacked by a group to deliberately mislead or blackmail; could metadata be used for unintended purposes such as spying on or annoying users.

With these risks in mind should there be standard mechanisms for securing metadata and verifying its source (such as signing certificates, encryption or white/black lists).

= Related Proposals, Research and Discussions =

* [http://www.mail-archive.com/whatwg@lists.whatwg.org/index.html#11037 WHATWG Discussions]
* [http://www.w3.org/2001/sw/interest/ w3c Semantic Web Interest Group (SWIG)]
* [http://lists.w3.org/Archives/Public/semantic-web/ W3C SWIG Mailing List Archive]
* [http://microformats.org/wiki/grddl GRRDL (Transformations of XHTML to RDF)]
* [http://www.xanthir.com/rdfa-vs-crdf.php RDFa vs. CRDF (Cascading RDF Proposal)]
* [http://research.talis.com/2005/erdf/wiki Embedded RDF Wiki]
* [http://research.talis.com/2005/erdf/wiki/Main/RdfInHtml RDF in HTML (Embedded RDF Examples)]
* [http://en.wikipedia.org/wiki/Semantic_web Wikipedia page on Semantic Web]
* [http://microformats.org/wiki/what-are-microformats What are Microformats? (microformats.org)]
* [http://www.foaf-project.org/ Friend of a Friend Project (FOAF)]
* [http://dublincore.org/ Dublin Core Metadata Initiative (DCMI)]

= Pre-Existing Software Systems That Demonstrate A Need =

* [http://www.kaply.com/weblog/operator/ Operator] - A semantic web processor for extracting metadata from all forms of HTML embedded by using Microformats and RDFa.
* [http://rdfa.digitalbazaar.com/fuzzbot/ Fuzzbot] - A semantic web processor for extracting triples from HTML4 and XHTML1.0, 1.1 and 2.0 data sources.
* [http://simile.mit.edu/wiki/Longwell Longwell] - Longwell is a web-based RDF-powered highly-configurable faceted browser.
* [http://simile.mit.edu/wiki/Piggy_Bank Piggy Bank] - Piggy Bank is a Firefox extension that turns your browser into a mashup platform, by allowing you to extract data from different web sites and mix them together. Piggy Bank also allows you to store this extracted information locally for you to search later and to exchange at need the collected information with others.
* [http://simile.mit.edu/wiki/Solvent Solvent] - Solvent is a Firefox extension that helps you write screen scrapers for Piggy Bank.
* [http://simile.mit.edu/wiki/Semantic_Bank Semantic Bank] - Semantic Bank is the server companion of Piggy Bank that lets you persist, share and publish data collected by individuals, groups or communities.
* [http://simile.mit.edu/wiki/Crowbar Crowbar] - Crowbar is a web scraping environment based on the use of a server-side headless mozilla-based browser. Its purpose is to allow running javascript scrapers against a DOM to automate web sites scraping but avoiding all the syntax normalization issues.
* [http://simile.mit.edu/wiki/Referee Referee] - Referee is a program that reads your web server logs and crawls your referrers (the links that point to your pages) and extract metadata from those pages and text around the links that pointed to your pages.

== Proposals ==

=== Inline (as multiple attributes) ===

Multiple new metadata attributes such as in RDFa.

* Pro: Reasonably simple to add to spec.

* Con: Dependent on changes to HTML spec for future changes to metadata spec.
* Con: Would probably require a different syntax for block or external version of same metadata (makes it hard to move).
* Con: Requires documentation and standardization in the HTML spec rather than through a separate document and standards body.
* Con: More potential for attribute name collisions with future HTML attributes.
* Con: Appears to make metadata reuse difficult.

=== Inline (in a single attribute) ===

One metadata attribute with complex content (such as the style attribute)

* Pro: New properties can be added without changing the HTML spec.
* Pro: Changing properties does not affect the DOM.
* Pro: The properties are grouped together.
* Pro: Requirements very similar to style="" and onclick="".

* Con: Requires new metadata format to be created.
* Con: Makes it harder to select individual property/value pairs through CSS or DOM scripting. (Might require dedicated APIs... Ugh.)

=== Block or external metadata ===

Metadata is defined elsewhere from element and targeted in the manner of CSS or Javascript.

* Pro: Does not clutter the HTML.
* Pro: Gives it more space to develop such as style did once it was abstracted from HTML.
* Pro: May be easier to import, export, reuse, sign and translate.
* Pro: May be applied to elements that the author cannot change attributes on (eg, dynamic, protected or generated content).
* Pro: Speed up where external metadata can be cached.

* Con: Requires new metadata format to be created.
* Con: CSS-like targeting or use of class or id to apply metadata adds complexity/indirection.

Generic Metadata Mechanisms

2008-09-23T14:59:07Z

Dean: /* Machine-readable */

There have been some requests for introducing generic metadata mechanisms into HTML5.

To help determine what we would need to add, and whether it is worth adding anything, we have to come to an understanding of what the goals and requirements are of such a proposal.

Please document arguments with links to supporting research or links to other wiki pages detailing the anecdotal evidence for or against particular aspects of the goals and requirements.

= Goals =

== What is the problem we are trying to solve? ==

'''Nobody has yet answered this in this wiki; please see http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-September/016186.html for commentary and advice on how to fill this in.'''

== Who faces this problem? ==

Currently a few groups. In the future metadata may become necessary for the average "web consumer" (human or machine) to sort actual information from presentation and structural cruft. In other words, a useful tool for determining the meaning, terms of use, quality and/or authority of a piece of data inside (X)HTML.

'''This section needs to be much, much more detailed. Who exactly faces the problem we're trying to solve? Name names of communities, organizations, companies, etc; show how they are "suffering" today and how they are currently working around the problem.'''

= Requirements: If we assume that we are going to address this need, what do we need to provide? =

Please demonstrate the reasoning behind each requirement, along with examples of how the requirements could be addressed.

== Machine-readable ==

A machine-readable and standardized way to apply semantic properties (metadata) to DOM elements in HTML5 (text/html) and XHTML5 (application/xhtml+xml).

'''Needs more detail. What does it mean to be machine-readable?'''

== Disambiguation ==

These properties are capable of being disambiguated between multiple definitions of the property name.

== Finding or defining meaning ==

We should be able to find or define an "authoritative" meaning for an abstract concept like "title" (eg. book title, job title, person's title, land deed, etc...).

'''Needs more detail. What does it mean to "find" an authoritative meaning?'''

== Machine-usability ==

The metadata could be read by UA's and other tools to perform actions that would not be possible without "knowing" what type of thing, quantity, unit or quality an element represents.

'''Needs more detail. How can this work? What does it mean in practice?'''

== DOM consistency ==

The DOM has to be consistent between HTML and XHTML representations. If it isn't, then migrating between the two becomes non-trivial, especially for scripting.

== Ease of deployment ==

The syntax has to be something that Web authors can easily deploy. If authors can't deploy this, then it won't get critical mass and won't matter.

One could argue that tools will be used to deploy this, that it'll mostly be used by big sites like Facebook, and that thus individual authors don't matter, but this kind of argument ("the tools will save us") has been repeatedly shown to not work, because in practice the tools have to be hand-authored too, and so the complexity is just moved to other people.

== Inlinability ==

It has to have a way to include it inline, so that it is quicker for non-professional developers to use and adopt. Also, putting metadata in the same location as content could prevent errors in updates or copying.

== Abstractability ==

It has to have both a way to abstract it from the HTML, like JS or CSS.

'''Needs more detail. Why does it need to be abstractable?'''

== Sustainability ==

Where possible the proposal should be resistant to temporary or permanent unavailability of an authoritative source (ie, vocabulary provider). This could be achieved, for example, through a P2P or DNS-like mechanism, or by not relying on external sources (e.g. in the way that SSL certificates are checked).

Not doing this would lead to failures during temporary outages or overloading of an authoritative source of metadata definitions, and may make it more resistant to hostile takeover or shutdown of authority.

Distributing an authoritative source needs not make it less authoritative.

== Reuse ==

The proposal should allow metadata and authoritative sources to be reused across elements, pages and sites, because web developers are more likely to use something that does not require repetitively typing the same data.

'''Needs more detail. Reuse how?'''

== Multilingual and Multicultural ==

Not all concepts can be expressed properly in English. A proposal should allow metadata for foreign languages and concepts.

== Authority and Security ==

Since a potential use of metadata appears to be enabling future features of UAs and other tools it follows that this opens the end-user to additional risks. For example, could a page author or hijacker feed a virus to a tool by falsely claiming it to be another type of data; could harm be caused when a metadata authority is hijacked by a group to deliberately mislead or blackmail; could metadata be used for unintended purposes such as spying on or annoying users.

With these risks in mind should there be standard mechanisms for securing metadata and verifying its source (such as signing certificates, encryption or white/black lists).

= Related Proposals, Research and Discussions =

* [http://www.mail-archive.com/whatwg@lists.whatwg.org/index.html#11037 WHATWG Discussions]
* [http://www.w3.org/2001/sw/interest/ w3c Semantic Web Interest Group (SWIG)]
* [http://lists.w3.org/Archives/Public/semantic-web/ W3C SWIG Mailing List Archive]
* [http://microformats.org/wiki/grddl GRRDL (Transformations of XHTML to RDF)]
* [http://www.xanthir.com/rdfa-vs-crdf.php RDFa vs. CRDF (Cascading RDF Proposal)]
* [http://research.talis.com/2005/erdf/wiki Embedded RDF Wiki]
* [http://research.talis.com/2005/erdf/wiki/Main/RdfInHtml RDF in HTML (Embedded RDF Examples)]
* [http://en.wikipedia.org/wiki/Semantic_web Wikipedia page on Semantic Web]
* [http://microformats.org/wiki/what-are-microformats What are Microformats? (microformats.org)]
* [http://www.foaf-project.org/ Friend of a Friend Project (FOAF)]
* [http://dublincore.org/ Dublin Core Metadata Initiative (DCMI)]

= Pre-Existing Software Systems That Demonstrate A Need =

* [http://www.kaply.com/weblog/operator/ Operator] - A semantic web processor for extracting metadata from all forms of HTML embedded by using Microformats and RDFa.
* [http://rdfa.digitalbazaar.com/fuzzbot/ Fuzzbot] - A semantic web processor for extracting triples from HTML4 and XHTML1.0, 1.1 and 2.0 data sources.
* [http://simile.mit.edu/wiki/Longwell Longwell] - Longwell is a web-based RDF-powered highly-configurable faceted browser.
* [http://simile.mit.edu/wiki/Piggy_Bank Piggy Bank] - Piggy Bank is a Firefox extension that turns your browser into a mashup platform, by allowing you to extract data from different web sites and mix them together. Piggy Bank also allows you to store this extracted information locally for you to search later and to exchange at need the collected information with others.
* [http://simile.mit.edu/wiki/Solvent Solvent] - Solvent is a Firefox extension that helps you write screen scrapers for Piggy Bank.
* [http://simile.mit.edu/wiki/Semantic_Bank Semantic Bank] - Semantic Bank is the server companion of Piggy Bank that lets you persist, share and publish data collected by individuals, groups or communities.
* [http://simile.mit.edu/wiki/Crowbar Crowbar] - Crowbar is a web scraping environment based on the use of a server-side headless mozilla-based browser. Its purpose is to allow running javascript scrapers against a DOM to automate web sites scraping but avoiding all the syntax normalization issues.
* [http://simile.mit.edu/wiki/Referee Referee] - Referee is a program that reads your web server logs and crawls your referrers (the links that point to your pages) and extract metadata from those pages and text around the links that pointed to your pages.

== Proposals ==

=== Inline (as multiple attributes) ===

Multiple new metadata attributes such as in RDFa.

* Pro: Reasonably simple to add to spec.

* Con: Dependent on changes to HTML spec for future changes to metadata spec.
* Con: Would probably require a different syntax for block or external version of same metadata (makes it hard to move).
* Con: Requires documentation and standardization in the HTML spec rather than through a separate document and standards body.
* Con: More potential for attribute name collisions with future HTML attributes.
* Con: Appears to make metadata reuse difficult.

=== Inline (in a single attribute) ===

One metadata attribute with complex content (such as the style attribute)

* Pro: New properties can be added without changing the HTML spec.
* Pro: Changing properties does not affect the DOM.
* Pro: The properties are grouped together.
* Pro: Requirements very similar to style="" and onclick="".

* Con: Requires new metadata format to be created.
* Con: Makes it harder to select individual property/value pairs through CSS or DOM scripting. (Might require dedicated APIs... Ugh.)

=== Block or external metadata ===

Metadata is defined elsewhere from element and targeted in the manner of CSS or Javascript.

* Pro: Does not clutter the HTML.
* Pro: Gives it more space to develop such as style did once it was abstracted from HTML.
* Pro: May be easier to import, export, reuse, sign and translate.
* Pro: May be applied to elements that the author cannot change attributes on (eg, dynamic, protected or generated content).
* Pro: Speed up where external metadata can be cached.

* Con: Requires new metadata format to be created.
* Con: CSS-like targeting or use of class or id to apply metadata adds complexity/indirection.