Re: Rethinking @src in the context of chaining rules

Mark,

We might be using slightly different meanings when we each say
"subject." (I know, what is "is", right?) So let me try to get at the
core of the issue here:

> remove the ability for @src to express an object, and replace it with
> being a subject.

That's not what I'm suggesting. I'm suggesting that @src behave like
@about: it can be an object when a chaining rule is used.

Thus, in my proposal, this works:

>   <div about="#ben" rel="foaf:depiction">
>     <img src="foo.jpg" instanceof="foaf:Image" />
>   </div>

but the following does *not* work:

>   <img about="#me" rel="foaf:img" src="foo.jpg" />

I think if you step back and forget that we had @src define an object
before, you wouldn't write that markup anyways. It can easily be written as:

<span about="#me" rel="foaf:img">
  <img src="foo.jpg" />
</span>

and I think that makes a *lot* more sense.


After all, if we write the following markup:

  <span href="#me" rel="foaf:knows" resource="#you" />

should we go down the path of: well @href shifts to subject and
@resource stays the object, and we get <#me> foaf:knows <#you>?

I sincerely hope the answer is clearly *no*, and the same conservative
approach should apply to other attributes: chaining allows us to give
them *static* roles: @about is a subject, @href is an object, each
defining its subgraph, and then @rel with chaining can hook portions of
those graphs together.

It's dangerous to try to make every possible case of markup mean
something, because that can have serious consequences on the overall
understandability of the entire spec.

Having @src shift from subject to object goes right back to the issue
you (and everyone else) justifiably complained about when I said
@instanceof could apply to @about or @resource.

> I don't see why we don't retain support for that. The presence of @rel
> is what turns some of the attributes into objects.

I *really* don't like that. The nice thing about chaining is that it
made the meaning of attributes *far* more consistent, and did away with
my @instanceof shiftiness. Now you want to reintroduce this uncertainty,
where you need to look at *all* attributes before you figure out the
meaning of a single one.

There's also no use case here, only markup taken from previous rules
that you're saying should "still work." I disagree with that design
approach: trying to make every markup approach work is a recipe for
overly complicated parsing rules.

Let's go back to a use case and ask: how would one write that? So far,
this rules does not enable more use cases or cleaner markup, it only
enables *different* markup at a very high cost to the simplicity and
understandability of the spec.

-Ben

Received on Monday, 7 January 2008 18:08:05 UTC