Re: Dumb Question

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