@xmlns
------ 						

Native OWP: 
	yes (for XHTML)

Serialization Agnostic:
	no

Decentralized Voc. Support:
	yes

Clear AT contract:
	??

Static provisioning:
	yes

Simplicity:
	yes for end users/authors; no for script developers

Appropriateness:
	yes (in XHTML)

----------------------------------------------------------------------
@hyphen space extension  						
----------------------- 						

Native OWP:
	yes

Serialization Agnostic:
	yes

Decentralized Voc. Support:
	moderately (any value should be approved by the HTML5 WG to get the validators running)

Clear AT contract:
	??

Static provisioning:
	yes

Simplicity:
	yes

Appropriateness:
	yes (modulo the registration mechanism which gives the values the official blessing)

----------------------------------------------------------------------
RDFa/MD 						
------- 						

Native OWP:
	yes

Serialization Agnostic:
	yes

Decentralized Voc. Support:
	yes

Clear AT contract:
	??

Static provisioning:
	yes

Simplicity:
	unclear; many claim it is complicated, others disagree. MD is probably (marginally) simpler than RDFa Lite. RDFa Full is definitely more complex, but that may not be needed.

Appropriateness:
	not really. The problem is what the subject is of a specific statement. If, say, an HTML page talks about an concert, RDFa/MD is typically used to add information about the _concert_, not about the <div> element holding the concert's description. Putting another way, RDFa/MD is appropriate to add information on a chapter as a whole, on the book as a whole, ie, a possible alternative to what DC terms are used for today. But may not be appropriate for, say, the 'intrinsic glossaries' use case.

----------------------------------------------------------------------
Custom Elements (using the upcoming Web Components Spec)						
-------------------------------------------------------- 						

Native OWP:
	yes (eventually, when the specification is published in final form)

Serialization Agnostic:
	yes

Decentralized Voc. Support:
	yes

Clear AT contract:
	At this moment probably not. ??

Static provisioning:
	Not really. A new element should be 'registered' through a simple script to be used properly, see, eg., http://www.html5rocks.com/en/tutorials/webcomponents/customelements/. That being said, the script may be very simple if the goal for the element is to be used by 'declarative' processes.

Simplicity:
	yes for end users; moderately for script developers

Appropriateness:
	yes

----------------------------------------------------------------------
@role 						
----- 						

Native OWP:
	yes

Serialization Agnostic:
	yes

Decentralized Voc. Support:
	Unclear; new values should probably be registered through a mechanism that is still to be defined by the PF Working Group (or the HTML Working Group?)

Clear AT contract:
	yes

Static provisioning:
	yes

Simplicity:
	yes

Appropriateness:
	yes, modulo the registration issue above

----------------------------------------------------------------------
@class 						
------ 						

Native OWP:
	yes

Serialization Agnostic:
	yes

Decentralized Voc. Support:
	yes

Clear AT contract:
	probably

Static provisioning:
	yes

Simplicity:
	yes

Appropriateness:
	Although the @class attribute is defined in very generic terms, ie, not only for styling, the practice is that it is mostly used for styling. As a consequence there is a major danger of value clash between styling and other purposes; as such, it is inherently error prone with very-difficult-to-find bugs. 

----------------------------------------------------------------------
@data-* 	
------- 						

Native OWP:
	yes

Serialization Agnostic:
	yes

Decentralized Voc. Support:
	yes

Clear AT contract:
	???

Static provisioning:
	yes

Simplicity:
	yes, both for end users/authors and for Javascript programmers, for whom even specific interface methods exist to handle them smoothly 

Appropriateness:
	per HTML5 specification, no.