Re: status of non-prefixed values in @rel

Ivan Herman wrote:
> Let us also realize that issue of the @rel="foo", ie, the issue of
> unwanted triples is, in fact, not specific to this case.

Indeed, although it is more likely that someone would write rel="foo"
without knowing about RDFa than someone writing rel="foaf:foo".

There are two additional flags here.

First, when someone defines an HTML profile, they sometimes mean to
affect the namespace of certain @rels. For example, rel="transformation"
with a GRDDL profile shouldn't generate xhtml:transformation, since
that's *not* what it is.

Second, a number of folks already use @rel in other ways, for example,
rel="modaldialog" in certain JS frameworks. Even if the triple is
meaningless, I'm not sure we want to generate one here, given existing
uses for HTML.

I'm more worried about (1), the *wrong* triple, than (2), an extraneous
meaningless triple, of course.

I still think the right solution is to generate nothing when it's not a
reserved word, *because* of HTML existing use, and I just don't see why
that's so difficult.

Mark, you said:

> I think everyone generally agreed with the 'preprocessor'
> approach, but since no-one ever wrote that up in any meaningful way,
> it meant that it was pretty academic.

I wrote it up and had it working quite well a while ago in my parser. I
temporarily disabled it while we figured out this issue. I'll reenable
the code and show you how it works later today. It's really quite
simple: ignore all values without a ":", and run a pre-processor to
update the DOM with the xh: prefix on reserved values.

-Ben