Re: HREF attribute in elements other than A and LINK

Hi guys,

In this post I propose taking a 'profile' approach to RDFa, so that we
don't use valuable features form RDFa when dealing with situations or
languages that may not be able to support them.


CONTEXT

Let's go back a step. Can we just agree that we all want to see RDFa
adopted? No-one has a monopoly on this, so it doesn't need to get
raised in every single discussion. I'm not sure if this is conscious,
but the moment someone plays the trump card of 'I want to see RDFa
adopted' it has the effect of implying that no further discussion is
necessary.

Also, I know this isn't the substance of the debate, but I haven't
always asserted that RDFa is about HTML authors per se; what I've been
saying is that RDFa is about making it easy for HTML authors to add
metadata that can then be consumed for RDF purposes. The argument goes
that if we don't make it easy, we don't get the triples we want, the
triples that we need to do clever things. So there is no 'one side or
the other'--I've always maintained that we need both sides of the
equation at the same time in order to make any progress with what we
like to think of as the 'semantic web'.


HTML AUTHORS AND @HREF

Now, it's certainly possible that authors will get confused by the
presence of @href on an element that is not <a> or <area>, but I very
much doubt it. For a start, they don't have to put it there--so if
they don't put it there in the first place, how can they get confused
by it! But let's say they see it in someone else's code; I really
don't find people thinking that, today, in HTML, the thing that gives
them a clickable link is the href attribute and not the presence of
the <a> or <area> elements. I don't see people getting confused about
<link> and <base>, for example, which also use @href. So I don't see
someone reading someone else's code and necessarily thinking, where is
the clickable link. But even if they did, what's the consequence? It
won't exactly result in plane crash or anything like that.

I think a number of assumptions are being made about the modern author
that don't reflect current trends. Mark-up is getting increasingly
sophisticated--by which I mean clearer, not more complex--and you only
have to read the hundreds of blogs out there from people who are using
HTML day in, day out, to see that there is a very high level of
understanding of what mark-up is all about. As it happens, people are
increasingly pushing the 'semantic' side of HTML.


HTML GUARDIANS' BACKLASH

However, even if we disagree on that first point, we certainly can
agree that there might be a 'backlash' from the guardians of HTML, and
we may decide that this is in itself sufficient to influence the
design of RDFa.

Of course, it should be said that no matter what we do there will most
likely be a push-back, and my experience of this in other areas is
that you cannot anticipate what it is that will be the substance of
that push-back. So I'm very uneasy at taking as our starting-point a
kind of 'guess' at what issues will get raised since what makes one
person think they are any the wiser as to where the disagreements will
come from than any other? The only way to truly guarantee agreement
from all quarters is to do nothing, after that it's purely
speculation.

(I do also think it's a shame that in these discussions people always
assume the worst, i.e., that we can't convince people in a genuine
discussion that some change is worth making.)


TWO-PRONGED APPROACH

But I think another problem in these discussions is that people like
to polarise before any discussion has even happened. The discussion
about @href is already in danger of escalating, with the red herring
of 'adoption' looming, so why not take a two-pronged approach to this;
let's say that at the moment it is not clear that this issue will give
us push-back. But let's also say that since none of us know what will
happen, we should prepare the ground in case this _is_ the source of
much controversy. In that case, what _exactly_ would be the proposal
on @href?

I haven't yet seen one, other than just a general notion of preventing
@href on 'extra' elements. So to be more specific, if we have to go
this route, should @href be prevented from appearing on all additional
elements only in HTML+RDFa, or in XHTML+RDFa as well? What about RDFa
more generally?

Also, since the arguments for not allowing @href apply also to @rel
and @rev, then only allowing @href/@rel/@rev on clickable link
elements ('a' and 'area') means we lose bnode support, so again, we
need to decide whether we lose bnode support in RDFa more generally,
or just in the HTML use of RDFa.

(Unless we're seriously considering the 'display: none' proposal.)


TOWARDS A PROFILE APPROACH

One way of coming at the 'preparing the ground' side is that we create
and document RDFa-Full, which has all the features we would desire,
and that an RDFa parser *must* understand. This would include
@href/@rel/@rev everywhere, nested link and meta, and so on. We then
have one place where all the rules and meanings can be found, and that
a parser writer would go to get guidance.

But then for author usage we say 'this is how RDFa is used in
HTML...this is how it is used in XHTML 1.x...this is how it is used in
XHTML 2'. That way, we have the flexibility to deal with the 'social'
issues that might arise in any community (and they may be different
again when producing SVG/RDFa), but we still only need one parsing
model (the one in RDFa-Full).

This means, for example, that if we also say that nested meta and link
are unworkable (or undesirable) in HTML+RDFa, it doesn't make any
difference to an RDFa parser that is presented with an HTML document,
since their absence means nothing.


CONCLUSION

My view remains that we should support @href everywhere, for the
reasons I've said. But I think we'll lose valuable time if we simply
polarise the discussion to being for or against that view. Instead we
need to ensure that whilst the broader discussion continues on the
authoring and 'social' points, we're also looking at what exactly the
consequences are (the loss of bnode support, for example) and whether
such changes should affect RDFa 'as such' or just the use of RDFa with
HTML. Losing features from RDFa more broadly, just to handle issues
that are specific to HTML, seems like using a hammer to crack a nut,
but adopting a 'profile' approach appears to give us a greater degree
of flexibility.

Regards,

Mark

[1] <http://www.formsPlayer.com/notes/xhtml-meta-data-03.html>


On 17/04/07, Ben Adida <ben@adida.net> wrote:
>
> (Chair hat off)
>
> Mark Birbeck wrote:
>
> [...]
>
> > My point about starting with a 'mental model' is only to suggest that
> > we look at how something fits with existing HTML, and existing
> > practice. The idea was simply that if we're happy with the model we
> > can look at how we explain it to other people. (It's actually how
> > nearly everything in RDFa has been designed, just not always
> > explicitly.)
>
> So, I'm not happy with the model of adding HREF everywhere in something
> called XHTML1.1+RDFa. Mark, you've always pointed out that RDFa is
> primarily aimed at HTML authors adding semantic markup. I mostly agree
> with you. With that assumption, I can only imagine an HTML author being
> thoroughly confused by HREF everywhere, wondering, "where's the
> clickable link? How do I *make* it clickable?". Why would an HTML author
> do this? What is the use case that would lead him to put an HREF on a
> DIV as far as the HTML author is concerned? This adds a whole level of
> inherently invisible metadata, where the primary goal of RDFa is to mark
> up visible data.
>
> Regarding acceptability of this approach, I'm in full agreement with
> Ivan on this: the backlash against this will be enormous. We *have* to
> plan for it, and, more importantly, we have to ask ourselves: what is
> the cost/benefit of this quasi-ensured backlash? I see a high cost, and
> I don't see the benefit wrt our goals.
>
> Finally, the biggest worry I have is regarding the perception of this
> change. If we add HREF in a bunch of places, we're really changing the
> document model for HTML in ways that even adding REL didn't do (since
> that is still about marking up visible content). It's not XHTML1.1
> anymore. It's clearly XHTML1.2. And the perception will be that we're
> trying to squeeze XHTML2 features into XHTML1 via RDFa. That is a
> dangerous proposition: we should not make RDFa an even bigger lightning
> bolt for criticism, if we can help it.
>
> -Ben
>
>


-- 
  Mark Birbeck, formsPlayer

  mark.birbeck@x-port.net | +44 (0) 20 7689 9232
  http://www.formsPlayer.com | http://internet-apps.blogspot.com

  standards. innovation.

Received on Wednesday, 18 April 2007 11:41:16 UTC