Re: Rethinking @src in the context of chaining rules

Mark Birbeck wrote:
> I think you've missed some of the key examples I've been trying to
> convey -- the roles are far from 'static'. Take this example:
> 
>   <div about="A" rel="p">
>     <div about="B" />
>   </div>

Do we really want to argue about a contrived example? What's the point
of this markup? Would anyone ever write this in a practical situation?

I would write:

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

or, if I had things to say about "B", I would do what you did above but
with actual properties hanging off of B.

We really shouldn't be arguing based on contrived markup.

> :) Today's newspapers are tomorrow's chip wrappers, as they say. Only
> the other day compliments were being handed out on how the spec was
> readable, clear, precise, and whatever else;

Saying that the spec is well written and that a small piece of it will
make things more complicated are not incompatible. Your contributions
have been fantastic, but I don't have to agree with all of your
proposals to think so!

[...]

> As I said before, I do actually think the parsing is much simpler.

Mark, we need to look at some facts: I pointed out how the chaining
model I (and others) understood means that you just *delete* two rules
from your proposed spec. Factually speaking, that makes the spec simpler.

More subjectively, your proposal gives many different ways of expressing
exactly the same thing with the same DOM skeleton (@resource and @about
become interchangeable in many cases). That makes things more
complicated. Multiple ways of doing exactly the same thing generally
leads to confusion, in my opinion.

> That's not true. The use-cases that I've outlined a few times now
> relate to consistency when moving items around, so that things that
> work in one context have the same behaviour in another. I don't
> believe that there are "high costs" to this, or that I am risking the
> simplicity of the spec -- quite the contrary.

There's no *need* to make things consistent with infinite moving around
of attributes if there's no good use case to justify it. So far, the
task force seems to think it makes things more difficult to describe and
implement, and "shuffling attributes around" is not a use case.

> What I'm finding a little frustrating in this part of the discussion
> is that no-one has responded to the very first question I asked, which
> I'll paste here again:
> 
> --- STARTS ---
> 
> On the issue raised, there are two important aspects to it, but the
> one I'll focus on here concerns consistency in chaining triples
> together. What would you see as being the parsed triples from this:
> 
>  <div about="A">
>    <div rel="p1" resource="B">
>      <div rel="p2" resource="C" />
>    </div>
>  </div>
> 
> I'm assuming we're happy with:
> 
>  <A> <p1> <B> .
>  <B> <p2> <C> .
> 
> What if we split the @rel's and @resource's:
> 
>  <div about="A">
>    <div rel="p1">
>      <div resource="B">
>        <div rel="p2">
>          <div resource="C" />
>        </div>
>      </div>
>    </div>
>  </div>
> 
> Any reason why this should not yield the same triples? I'm hoping not.
> 
> --- ENDS ---

You're wrong, I did answer this: the reason they should not yield the
same triples is because, to enable this feature, we have to have
additional rules in the parsers, and we now have to explain to users why
we have two different ways of expressing the exact same thing: in your
second example above, just replace resource="B" with about="B" and
resource="C" with about="C": do we need to have those two ways of doing
the same thing? I think not.

"Moving stuff around", when you originally motivated it, was about
taking a chunk of markup:

<div about="#foo">
  ... lots of triples ...
</div>

and putting it inside a rel:

<div rel="a:b">
   <div about="#foo">
     ... lots of triples ...
   </div>
</div>

and having that "do the right thing." That argument completely convinced
me regarding your chaining approach, because that's how data publishers
will think: let me mark up a bunch of triple, and oh that now has to
become the object of that, so I'll move that block over there.

But will a data publisher suddenly feel the need to break up his @rel
and @resource? That doesn't fall under the category of "moving stuff
around" in the same way at all. I just don't see it, and no use case is
enabled by this.

So I'm still very much against this.

> Can anyone answer that last question? I.e., explain why this mark-up
> should yield exactly *zero* triples? I've never said that we should
> *promote* this mark-up, merely that we should support it if we come
> across it.

I disagree with that argument. Supporting more markup has costs, and in
this case there are no benefits other than "supporting more markup."

-Ben

Received on Monday, 7 January 2008 22:54:51 UTC