Re: XHTML Vocabulary

On Dec 13, 2010, at 11:22 , Toby Inkster wrote:

> 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?

Works for me. And yes, we have to discuss this issue at some point.

One thing, however, putting my dull administrative hat on: any policy we decide is just an advise and I would have to get it through W3C's admin. Indeed, this Working Group cannot define a policy that would be valid beyond the existence of the group...

> I've been working on a replacement for the current XHTML vocabulary
> document. The current draft is here:
> 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.

The problem is with the choice of Dublin Core and CC. They do make sense, of course, but people may come and ask us to make mappings to other vocabularies, too! How would we decide that?

> 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.

What do you mean by 'via'? I presume the idea is that W3C Working Groups may add terms that are part of a W3C recommendation, right?

> 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.

Hits Proposed Recs. As we see with the discussion on our own Last Call, things may change as a result of community comments; ie, it would not be stable yet. Actually, maybe the change should happen at the Recommendation phase only if we _really_ want stability.

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

Yes but my comment applies: PFWG can also give its opinion, but the decision should come from W3C, essentially the guardian of the process:-)

> 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 <>.

I agree.

> 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.

See above. I think the file might have to be maintained by W3C Activities rather than groups if we envisage evolution beyond the groups.

> 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.

I do not see why not...:-)

That being said, let us not underestimate the admin requirement of an IETF registration...

> 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 <>, filled in
> appropriately for each of the relations. This should be a document with
> a permanent URL in 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.

I last point, only related. From an RDF(a) point of view I would seriously consider adding prefix definitions to the profile file, too. The only thing we can do without controversy is to add the prefixes for all relevant W3C recommendations: rdf, rdfs, owl, skos, powder, rif, etc. It does not cost much to add and can be useful... Although I would not bother turning them into terms of sets. Just prefixes.


> -- 
> Toby A Inkster
> <>
> <>

Ivan Herman, W3C Semantic Web Activity Lead
mobile: +31-641044153
PGP Key:

Received on Monday, 13 December 2010 12:35:54 UTC