- From: Shane McCarron <shane@aptest.com>
- Date: Fri, 01 Jun 2007 11:09:58 -0500
- To: Ben Adida <ben@adida.net>
- CC: mark.birbeck@x-port.net, Dan Brickley <danbri@danbri.org>, Elias Torres <elias@torrez.us>, RDFa <public-rdf-in-xhtml-tf@w3.org>
Just to punctuate this.... I consider this splitting of specs an editorial change, not a substantive change. The only substantive bit is re-introducing this @resource thing, which I think is a WONDERFUL change. Thanks for championing this Mark; I obviously got distracted. Life.... Don't talk to me about life. And me with a pain in the diodes all up and down my left side. Ben Adida wrote: > In case Mark's email was still too long for Elias's spinning head... :) > > There was consensus on the call yesterday that we cannot make RDFa a > moving target anymore. There may be small additions (like @resource), > but all currently written RDFa is going to keep working, and the > additions will be minimal. The discussion around these last small tweaks > may be a bit involved, as this is the last stretch, but the result will > be simple. > > Hope this helps calm fears! > > -Ben > > Mark Birbeck wrote: > >> 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 >> >> > > -- Shane P. McCarron Phone: +1 763 786-8160 x120 Managing Director Fax: +1 763 786-8180 ApTest Minnesota Inet: shane@aptest.com
Received on Friday, 1 June 2007 16:10:46 UTC