Re: Rethinking @src in the context of chaining rules

Hi Ben/Ivan,

I've put the proposed vote at the bottom of the email. I have a few
more comments, first though:

On 08/01/2008, Ben Adida <ben@adida.net> wrote:
> Mark Birbeck wrote:
> >>>   <div about="A" rel="p">
> >>>     <div about="B" />
> >>>   </div>
>
> > Now I am even more confused than before...I thought at least that this
> > example was agreed upon.
>
> Let me be clear so that this doesn't hold up work on the spec: of course
> the example above works as we agreed. I'm just saying that it's an edge
> case of the chaining rules, and drawing deep conclusions from it is not
> productive.

Mmm...

Moving swiftly on. :)


> So yes, the above example yields
>
>   A p B .
>
> But that doesn't mean that your other arguments follow: ...

There were no other arguments. I was pointing out that it is not true
to say that the definition of the attributes was "static", which was
the word you used. Even in that simple example you can see that @about
is both a subject and an object, even without a second sub-graph.


> ... to me, this is
> still about hooking up two subgraphs, only the contained one happens to
> only have one vertex and no edges. It's an edge case (hah, no pun intended.)

A graph is made up of complete triples though. So a sub-graph can't be
made up of a vertex (e.g., just a subject)...it doesn't mean anything.


> To your point here:
> > I've stopped working on the syntax document for now, because no-one
> > seems to know precisely what it is that they want here.
>
> Actually, I think a number of folks are in agreement with me right now!
> At least that's the impression I got from the last telecon.

Yes, it's a shame I wasn't able to make that call.

Anyway, a few emails ago you seemed to suggest that the example above
shouldn't generate any triples, which I'm not sure everyone would have
agreed with. But now that we agree it should, I can move on a bit. I
know what everyone is worried about, so I can work through that.


> And, as I've said, the *only* difference in the spec is taking out those
> two rules on the setting of the current_subject.
>
> I also think Ivan's latest point is tremendously important:
>
> > how can the user *avoid* the appearance of certain triples?
>
> What Ivan is hinting at here is that we may be going down the rabbit's
> hole we had 2 years ago, where far more triples were being generated
> than we wanted.

More than _some_ wanted. :) You are referring to @class, I take it,
which was hardly a rabbit hole.


> Indeed, if I have a hanging @rel, then it seems that any contained link
> will generate a triple, and I only get to control *what* that triple
> says, not whether or not it appears.

But that's like saying if I put an @about on a <div> we no longer have
the 'normal' functionality of HTML with respect to @rel/@href, since
the relationship is no longer between the 'current document' and the
navigable link. That's the way it goes.


> Mark, yes, this is probably not what you originally proposed. But what
> you originally proposed was understood a certain way by me, Manu, and
> Ivan (and probably a few more people), and we ran with it. And it turns
> out that, looking back at the additional properties we didn't originally
> understand, there are notable downsides and very little upside.
>
> Maybe what we mistakenly understood turns out to be slightly better?

No, I really don't think it is better. And if it's arrived at via a
misunderstanding, I'm not sure if it is likely to be. :)

But anyway, given how long it took to even get to that point of
agreement on chaining, I'm wary (and weary) of pursuing this further.
As far as I can tell, not supporting this particular feature on
@resource and @href does not prevent it from being introduced in the
future, should the discussion go that way. So if we have a vote, I
really don't mind which way it goes, since it's obviously better to
get the document finished.

(I'm not indifferent about @src I'm afraid, hence the separate thread.)


> > the ability to apply a single @rel to a number of @href's and @resource's.
>
> That's the one small advantage I see, but it comes at a large cost as
> shown by Ivan, and it can be written differently, simply by repeating
> the @rel.

The advantage is consistency. You are referring here to the *third* of
the 'small advantages'.


> I think we're going to have to bring this to a vote.

Ok...let's do it.

Provided that the vote is specifically about @resource and @href then
it doesn't prevent us from looking at this in the future (if we want
to), in particular when we have more time. In which case I'm easy
about the result.

I believe that the vote can be quite simply put; accepting that this mark-up:

  <div about="A">
    <div rel="p1">
      <div about="B">
        <div rel="p2">
          <div about="C" />
        </div>
      </div>
    </div>
  </div>

yields two triples, should the following mark-up:

  <div about="A">
    <div rel="p1">
      <div resource="B">
        <div rel="p2">
          <div about="C" />
        </div>
      </div>
    </div>
  </div>

also yield two triples? Or should it yield zero?

Vote now......


NOTE: This actually comprises two separate questions, but I don't see
any point in taking them separately; if people don't feel comfortable
with this now I'd rather save the whole topic for a fuller discussion
in the future. Just so that everyone can see what the issues are, the
first question amounts to whether a hanging rel can be completed by
@resource on its own:

  <div about="A">
    <div rel="p1">
      <div resource="B" />
    </div>
  </div>

and this is the one that Ivan is unhappy about. The second question is
whether @resource on its own can be a subject:

  <div resource="B">
    <div rel="p2">
      <div about="C" />
    </div>
  </div>

and this seems to be the one that Ben is unhappy about.

Although no doubt each is unhappy about the other's, ;) it's just that
these are the positions that they have been arguing.

Regards,

Mark

-- 
  Mark Birbeck, formsPlayer

  mark.birbeck@formsPlayer.com | +44 (0) 20 7689 9232
  http://www.formsPlayer.com | http://internet-apps.blogspot.com

  standards. innovation.

Received on Tuesday, 8 January 2008 17:25:49 UTC