Re: Dumb Question

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
>

Received on Friday, 1 June 2007 15:25:33 UTC