Although overall I'm in agreement with Micah on the implementation, I still
think that there should be a push back on the HTML community for namespace
support - or this particular architecture needs to be extended to the XHTML
5 version as well. The danger I see is that you'll continue to see vendors
choose only to support the HTML only version (thinking IE8 here
specifically) event though both versions should technically be supported,
because of the potential of creating lock-in on the default namespace set.

One additional possibility here might be to introduce a new HTML 5 header
element called <extends>:

<extends namespace="*namespaceURI*" prefix="*prefix*" uses="*elementSeq|**">

Yes, this is a rogue namespace. The @uses attribute would contain either a
list of supported elements or would default to the total set of elements
(the default if @uses is not included. Elements in this namespace would be
used sans prefix identifiers, unless the need to resolve conflicts arose, at
which point it would take the form *prefix*.*element*. A dublin core element
would then be added as:

<extends namespace="http://dublincore.org/documents/dcmi-namespace/"
prefix="dc" uses="*"/>

or

<extends namespace="http://dublincore.org/documents/dcmi-namespace/"
prefix="dc"/>

Then inline you could have the <creator> or <editor> element being added
into the mix. If there was a collision with an extant namespace, then you'd
default back to <dc.creator>.


This would be on top of the core arrangement discussed by Micah - in
essence, it does not penalize developers who DO need advanced functionality
simply because of the Granny Coder argument.