Re: Dumb Question

Dan/Elias,

On 01/06/07, Dan Brickley <danbri@danbri.org> wrote:
> Elias Torres wrote:
> >
> > My head is spinning. We'll never finish. :(
>
> I'm afraid that was my gut reaction to these latest (post-xtech) threads.
>
> - "Oh crap, everything's changing again" -

I'm sorry that this is your perception because the threads are
actually about *resolving* issues! Maybe the posts are too long to be
read thoroughly ;) and it just _looks_ like it's all change.

Anyway, I'll recap for you, and then you can tell me whether you are
still concerned.....


@HREF EVERYWHERE

The context for all of this is '@href everywhere'; we've had this in
RDFa for a few years now, but recently the objection has been raised
that some authors might get confused, and think that mark-up like this
represents a clickable link:

  <span rel="a" href="b">hello</span>

There are some who disagree with that view (myself, Steven, Shane) and
there are those who think this is something that could affect the
adoption of RDFa (Ivan, Ben).

Speaking only for myself, I don't see it being crucial to the adoption
of RDFa, since that seems to be picking up speed nicely already. And I
also don't see it as being confusing for authors, since:

  * authors are already doing it;

  * authors new to RDFa are unlikely to actually use or see this
construct, since
    they will usually be dealing with 'clickable links'.

But what the heck...I'm really not that bothered about it, and we need
to resolve all disagreements somehow. But the problem with finding a
resolution is that the only justification I've seen for this change to
@href is that 'authors _might_ find it confusing', and when things are
expressed only as a matter of opinion, we unfortunately will often
reach an impasse.


BRING BACK @RESOURCE

So I decided to devote some time to finding a resolution, and it
turned out that a simple solution was available--to resurrect the
@resource attribute which was in the original drafts of RDFa. But this
time, we'd keep our interpretation of @href; in other words, we'd have
two attributes, but playing slightly different roles. This actually
seemed to me not just a compromise, but to be actually a better
solution than '@href everywhere' was. This is because:

  * it gives us a way of indicating an object that's a resource,
independent of host
    language;

  * it allows us to define resources that are non-navigable.

This last point is quite important, since in XHTML 2 @href _does_ mean
a navigable link anywhere it appears, so this would have been a
problem in the future. For example, if we were defining some kind of
SKOS relationships where there is no navigable end-point, we'd end up
with a 'navigable link' in XHTML 2, because that would be the only way
to express it.

So that's the state of play on that issue, and although not everyone
is convinced that this is the best solution (for example, as Steven
rightly says, you now need to understand two attributes), at least it
gives us a way out if we want it.


RDFA-CORE

Ok...that's the debate about @href and @resource. How does that relate
to the discussion on having a notion of RDFa-core?

My RDFa-core posts were simply about trying to have a 'model' of RDFa
that stops us getting into these kinds of situations, where anything
is fair game for change, and the criteria for change is largely
subjective. Personally I'm not wedded to any one syntax, but what I am
wedded to is consistency--that is after all the whole point of RDFa.
So whilst I won't get worked up about having @href everywhere--or
not--what I do want to ensure is that there is some kind of consistent
picture that helps people understand RDFa.


LINK AND META EVERYWHERE

To illustrate the problem I'm trying to address, let's look at another
issue (which is not actually in the issue-tracking system) 'link/meta
everywhere'. Just as we had '@href everywhere' for a long time, so too
we have <link> and <meta> everywhere in RDFa. But it transpired a
short while ago that some browsers move the link and meta elements
into the head of the document, losing all the important context
information. This means that we might as well remove that feature from
RDFa-in-HTML since it can't be supported.

But that means that we now we have *two* changes that are not based on
anything intrinsic to the language: we've removed 'link and meta
everywhere' because some browsers won't support it, and we've removed
'@href everywhere' because it might be confusing for authors.

You have to ask: what changes could be next? And what criteria could
be used to justify them? And you also have to ask, where does that
leave a language that _could_ support some of these features, such as
'link and meta everywhere'? It seemed to me that trying to squeeze
language-specific features like this into RDFa itself, was going to
cause us problems for future host languages.

So my suggestion is to simply say, why don't we 'unwind' all changes
that we made to the host language, and make a rule that we don't
actually change the host language at all. I appreciate that it might
unnerve you :), but it's not actually such a big change in terms of
work on the syntax, and it closes off some issues (9, 7(7), 12 and 34)
without much need for debate. (Fingers crossed.)

Also, by making clearer, the distinction between core attributes (like
@about and @resource), and an 'interpretation' of HTML (like '@rel is
the predicate'), it also points towards a possible solution to issue
3, because we could just add a new attribute for rdf:type to the core
attribute list.

I'm really hoping that this gives you a picture of why I'm proposing
what I am, and that it's all about trying to close off the few
remaining issues, rather than making enormous changes.

Regards,

Mark

-- 
  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 Friday, 1 June 2007 13:06:50 UTC