XHTML Vocabulary

There are a number of things I'd like to discuss with the WG surrounding
the XHTML vocabulary. It would be nice if we could schedule some time on
one of the calls to resolve some things, etc. Perhaps 6th Jan?

I've been working on a replacement for the current XHTML vocabulary
document. The current draft is here:

http://buzzword.org.uk/2010/xhtml-vocab-20101110.xhtml

The main update is to add mappings between XHTML vocabulary terms and
other common vocabularies including Dublin Core, RDFS, Creative Commons
and the IETF Link Relations registry.

Firstly, I'd like us to vote on a revision policy for this document. If
parser developers are going to hard-code or aggressively cache the
vocabulary, they need to be confident that they know how and when it's
going to change.

My proposed policy is this: New terms may only be added via W3C Recs. A
dedicated low-traffic mailing list would be provided by the W3C for the
announcement of new terms. New terms must be announced on that list
either three months before they're added to the vocab, or when the
specification defining them hits Last Call - whichever comes first.

Any policy probably also needs to be agreed to by PFWG and any other
groups with a vested interest in the XHTML vocabulary.

Secondly, I'm proposing we add describedby to the XHTML vocabulary's
profile, but not the the vocabulary itself. That is describedby would be
an RDFa term that mapped to a full URI outside the XHTML vocabulary. The
full URI would be <http://www.w3.org/2007/05/powder-s#describedby>.

Thirdly, the introductory text above even the Introduction section needs
reworking. The XHTML2 Working Group is effectively defunct. There is
probably some sort of lengthy process for RDFa WG / PFWG to officially
take over maintenance of the document. Steven, in your position as HTML
Activity Lead, would you be able to help arrange this? Assuming of
course that you agree it's a good idea.

Lastly, while most of the terms in the XHTML vocabulary are also
registered in the IETF Link Relations registry, six are not. While
there's no technical reason we need them to be registered, I think the
WG should attempt to register them so that the terms can also safely be
used in other non-RDFa places where "rel" can be used (e.g. plain,
non-RDFa Atom; and HTTP Link headers). One of the IETF Designated
Experts for the registry has told me he thinks it's a good idea to
register them.

The six terms are:

* cite
* itsrules
* meta
* p3pv1
* role
* top

I'd expect "cite", "meta" and "top" to not be controversial. 

However "role" is an interesting one in that it's a term in the vocab
that we don't really expect to be used as a rel value much - it's more
intended as support for the @role attribute.

We may need to review how "p3pv1" and "itsrules" are defined. RFC 5988
says:
|  Registered relation types MUST NOT constrain the media type of the
|  context IRI, and MUST NOT constrain the available representation
|  media types of the target IRI.  However, they can specify the
|  behaviours and properties of the target resource (e.g., allowable
|  HTTP methods, request and response media types that must be
|  supported).

So for example we might need to redefine "p3pv1" which is currently
described as "p3pv1 refers to a P3P Policy Reference File" and broaden
it to allow other media types - e.g. "p3pv1 refers to a resource serving
as a privacy policy, usually available as a P3P Policy Reference File".

To register the Link Relations, we'd need to publish a copy of the
template <http://tools.ietf.org/html/rfc5988#section-6.2.1>, filled in
appropriately for each of the relations. This should be a document with
a permanent URL in w3.org address space - it could be as an appendix to
XHTML+RDFa, but given that we're in Last Call for that perhaps changes
are undesired.

So anyway, I'd like to discuss this on the 6th Jan telecon, if that's OK
with the chairs. It would be good if we could as much discussion as
possible about the above issues done on the mailing list, so that when
the telecon comes round we can quickly run through resolving them all,
and not take up too much telecon time.

-- 
Toby A Inkster
<mailto:mail@tobyinkster.co.uk>
<http://tobyinkster.co.uk>

Received on Monday, 13 December 2010 10:22:46 UTC