Philip,
Philip Taylor wrote:
Seeing as people are implementing RDFa parsers for text/html, I guess
it would be good to have a specification that says how they should work.
http://www3.aptest.com/standards/rdfa-html/ doesn't answer the
questions I'd want answered (e.g. in
http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009May/0102.html),
and HTML 4 seems to make it impossible to express an answer.
I'm sorry that my draft "profile" document doesn't answer your
questions. Of course my intent is to evolve that profile so that, in
conjunction with the other RFCs, Candidate Recommendations, and
Recommendations it normatively references, it represents a thorough
description of the model for embedding RDFa in HTML documents.
I've not seen anyone else working on this, so I started writing a
rough draft at <http://philip.html5.org/docs/rdfa/>. Some of it is
copied from the RDFa-in-XHTML specification, and just tweaked to use
some new definitions and to share concepts (like base and lang) with
HTML 5 and to cope with text/html parsing (for xmlns:* attributes).
The CURIE definitions are new, since I didn't see any existing
document that defined them in an appropriate way.
Well - here we are going to have to disagree. Copying materials from
other specifications and then modifying those materials is a good way to
get divergence. The reason the document I prepared is very thin is that
there is no need, in my opinion, to duplicate materials. If there are
things in the CURIE spec that need clarification, then that is the place
to fix those. If there is confusion about the processing model for RDFa
as defined in its Recommendation, then we should issue errata or
re-issue the Recommendation. Any other way lies madness, IMHO.
There are several unresolved design issues (e.g. handling of
case-sensitivity, use of xmlns:* vs other mechanisms that cause fewer
problems, etc) - I haven't intended to make any decisions on such
issues, I've just attempted to define the behaviour with sufficient
detail that it should make those issues visible.
Yes, and you brought those issues up in a response to my announcement.
Thanks for that. I have been incorporating feedback from you and others
into a revision, and hope to have an updated draft available shortly.
The current draft is far from complete or correct, but it shows
roughly the way I'd like to have things defined (and I hope it's
roughly the way that HTML5/WHATWG people would like it to be defined,
in order to support implementers and to be testable), and maybe it
could end up being useful for something, so I'm just throwing it out
here for discussion.
There is always room for documents that expand on the normative
definition. Heck, there are whole publishing companies that grew up
just to deal with that! If the intent of your document is to expand the
discussion and provide additional data for people building
implementations, I think that's great! If the intent is to act as the
basis for some new specification, I think that is very bad. It
duplicates and changes existing Recommendations and Candidate
Recommendations. That can't end well.
Personally, I would rather have a quality test suite that exercises the
specification and ensure that suite gets extended to clarify any edge
cases that implementors are curious about. For example, I feel the
CURIE syntax definition is very clear. But I could see how people would
ask questions like "is 0:lala" a legal CURIE? The answer is clearly no
from the spec, but having a test that ensured such a CURIE was ignored
by a conforming processor would be a fine thing. And FWIW this sort of
thing happens in the RDFa Task Force all the time.
Let's work together to get your questions answered by the right people
in the right places.
--
Shane P. McCarron Phone: +1 763 786-8160 x120
Managing Director Fax: +1 763 786-8180
ApTest Minnesota Inet: sh...@aptest.com
