- From: Mark Birbeck <mark.birbeck@x-port.net>
- Date: Fri, 1 Jun 2007 14:06:46 +0100
- To: "Dan Brickley" <danbri@danbri.org>
- Cc: "Elias Torres" <elias@torrez.us>, RDFa <public-rdf-in-xhtml-tf@w3.org>
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