Re: chaining-friendly rules for @instanceof

Mark,

I am sorry, but you make this very difficult for some of us. I think the
majority of the participants of this TF, including myself, have no idea
what you are talking about when you refer to 'old chaining rules in
RDFa'. And, frankly, I do not have the time, nor the will, to go back to
old mails and archives which are probably two years old...

Bottomline: would it be possible for those of us who are newbies in the
group to summarize what would be your proposal at this moment to solve
the @instanceof deadlock? So that we could compare the two and make a
decision?

Thanks

Ivan

Mark Birbeck wrote:
> 
> Hi Ben,
> 
> I've written and re-written the following post umpteen times, over the
> last month or so. :) Finally, I've decided that the best way to break
> this down is to explain why I disagree with your approach, and then
> separately to spell out the extra couple of rules we need to make your
> use-cases work. All attempts I've made to mix the two have been even
> longer than this email...and as you can see below, this shortened
> version is still pretty long!
> 
> So, here goes...
> 
> You wrote:
>> Manu wanted me to express my proposed @instanceof rules in a way similar
>> to what he recently posted [1], so that we could compare.
>>
>> The main driver for my rules is to make it easy for @instanceof to be
>> used on chaining nodes, so that one can say "I know a person named
>> 'Ralph'", or even the more complicated "I know a person who knows a
>> person who knows a person named 'Bill'".
> 
> The statements:
> 
>   I know a person named 'Ralph'
> 
> and:
> 
>   I know a person who knows a person who knows a person named 'Bill'
> 
> were both always possible in earlier versions of RDFa, and in my view,
> in a way that is simpler than in your proposal. So before I go into
> that, some context.
> 
> 
> CONTEXT
> 
> What I believe has happened is this; chaining was removed from RDFa in
> the first draft that was produced within the taskforce, because it was
> deemed too complicated. After a while--and probably many use-cases :)
> --you proposed the idea that @href, @src, etc., should set the subject
> of contained statements, which was both an insightful idea, and
> effectively a 'reintroduction' of chaining. :)
> 
> However, there are a number of other aspects to chaining that need to be
> 'reintroduced' if we are to make it completely consistent, and I think
> it is the lack of these that makes your proposal not quite hang together
> (in my view). I don't think I can explain them all in this posting, but
> what I do think is important to do first--which I will do here--is to
> explore the problems with your 'rules', and to look at why I think they
> create unnecessary inconsistencies with attribute behaviour, without any
> gain.
> 
> (Sorry to put it so bluntly!)
> 
> 
> CONSISTENCY
> 
> I'll begin with your first statement, that:
> 
>   I know a person called Ralph
> 
> To indicate this, if we had all of the 'old' chaining rules in RDFa,
> then *any* of the following constructs could be used:
> 
> ========
> <div about="#me">
>   <div rel="foaf:knows">
>      <div instanceof="foaf:Person">
>        <span property="foaf:name">Ralph</span>
>     </div>
>   </div>
> </div>
> ========
> 
> ========
> <div about="#me">
>   <div rel="foaf:knows">
>      <span property="foaf:name" instanceof="foaf:Person">Ralph</span>
>   </div>
> </div>
> ========
> 
> ========
> <div about="#me" rel="foaf:knows">
>      <div instanceof="foaf:Person">
>        <span property="foaf:name">Ralph</span>
>     </div>
> </div>
> ========
> 
> ========
> <div about="#me" rel="foaf:knows">
>    <span property="foaf:name" instanceof="foaf:Person">Ralph</span>
> </div>
> ========
> 
> Note the consistency as the mark-up is expanded and contracted--by which
> I mean that elements are added and removed--the rules always stay the
> same, regardless of the presence of other attributes. In fact, if you
> removed the _elements_ and left behind only the attributes, every single
> one of these constructs results in the same structure:
> 
>   about="#me"
>     rel="foaf:knows"
>       {bnode}
>         instanceof="foaf:Person"
>         property="foaf:name"
>           content="Ralph"
> 
> This is obviously desirable, and is no accident.
> 
> Before I look at your rules in more depth, Ben, I'd like to continue to
> demonstrate the consistency of the 'complete' set of chaining rules that
> we used to have (which as I said, I'll go into in another thread). We'll
> take as our starting-point the last piece of mark-up, i.e., this one:
> 
> ========
> <div about="#me" rel="foaf:knows">
>    <span property="foaf:name" instanceof="foaf:Person">Ralph</span>
> </div>
> ========
> 
> and use it as a base from which to build up to your more complicated
> scenario:
> 
>   I know a person who knows a person who knows a person named 'Bill'
> 
> However, let's make the example slightly more realistic, by adding more
> information--we'll give each of the people down the chain a name, as
> follows:
> 
>   I know a person named 'Ralph', who knows a person named 'Ivan', who
> knows a
>   person named 'Bill'
> 
> Having established where we're heading, we need to do one last minor
> piece of preparation, and that is to slightly reorganise the mark-up so
> that we use @content instead of an inline literal; this makes the
> examples easier to read as they get more complex, and of course, it
> makes it easier to 'nest' elements, one inside the other.
> 
> So, our first statement, from which we will build up, now looks like this:
> 
> ========
> <div about="#me" rel="foaf:knows">
>   <span
>    instanceof="foaf:Person"
>    property="foaf:name" content="Ralph"
>   >
>   </span>
> </div>
> ========
> 
> The next step is to simply cut-and-paste Ralph (painless, I hope), in
> order to create a third person that looks exactly like the second one,
> but with the name value set to 'Ivan':
> 
> ========
> <div about="#me" rel="foaf:knows">
>   <span
>    instanceof="foaf:Person"
>    property="foaf:name" content="Ralph"
>   >
>     <span
>      instanceof="foaf:Person"
>      property="foaf:name" content="Ivan"
>     >
>     </span>
>   </span>
> </div>
> ========
> 
> Note that the only difference between this 'person' and the one we
> already had was that @content is set to 'Ivan' instead of 'Ralph', but
> the structure is exactly the same.
> 
> Once we've added this extra 'person' item, all we should have to do is
> to add an additional predicate to the second item (i.e., Ralph), to
> indicate the relationship between the two people:
> 
> ========
> <div about="#me" rel="foaf:knows">
>   <span
>    instanceof="foaf:Person"
>    property="foaf:name" content="Ralph"
>    rel="foaf:knows"
>   >
>     <span
>      instanceof="foaf:Person"
>      property="foaf:name" content="Ivan"
>     >
>     </span>
>   </span>
> </div>
> ========
> 
> As you can see, the only difference between the mark-up that expressed
> two _unconnected_ people (i.e., the previous step), and the mark-up that
> has two _connected_ people, is at line 5; it is there that we have added
> the extra predicate to the second item (Ralph) that indicates a
> relationship with the third item (Ivan).
> 
> The first thing that is important here--although the significance is
> probably quite obvious--is the way that I created the 'inner' item by
> cutting-and-pasting an item from elsewhere; the consistency of the
> language means that you can just 'drop' items from different places into
> position. In addition, we can keep adding child elements, getting deeper
> and deeper, as much as we like.
> 
> The second thing that is worth noting is that adding the @rel to
> establish the relationship between the two items is nothing more than
> adding a predicate to an item, and so does not change that item in any
> way. I'll say more on this below, but at this point the key thing to
> note is that adding and removing the @rel only changes the relationship
> between the items, and changes nothing about the item itself.
> 
> Anyway, let's continue, and finish your more complex scenario; we need
> to add:
> 
>   Ivan knows a person called 'Bill'
> 
> As before, first we add a self-contained 'person' item:
> 
> ========
> <div about="#me" rel="foaf:knows">
>   <span
>    instanceof="foaf:Person"
>    property="foaf:name" content="Ralph"
>    rel="foaf:knows"
>   >
>     <span
>      instanceof="foaf:Person"
>      property="foaf:name" content="Ivan"
>     >
>       <span
>        instanceof="foaf:Person"
>        property="foaf:name" content="Bill"
>       >
>       </span>
>     </span>
>   </span>
> </div>
> ========
> 
> and then, as before, we add the relationship between Ivan and Bill:
> 
> ========
> <div about="#me" rel="foaf:knows">
>   <span
>    instanceof="foaf:Person"
>    property="foaf:name" content="Ralph"
>    rel="foaf:knows"
>   >
>     <span
>      instanceof="foaf:Person"
>      property="foaf:name" content="Ivan"
>      rel="foaf:knows"
>     >
>       <span
>        instanceof="foaf:Person"
>        property="foaf:name" content="Ben"
>       >
>       </span>
>     </span>
>   </span>
> </div>
> ========
> 
> 
> SUMMARY OF POSITION
> 
> Now, hopefully what's obvious after having carried out the same process
> twice is that:
> 
>  * the attributes behave consistently;
> 
>  * @instanceof always applies to the subject on an element (possibly a
> bnode), and not the object.
>    In this, therefore, it does not differ from the setting of any other
> predicate;
> 
>  * items can be easily cut from one document and dropped into another,
> as self-contained
>    building-blocks that stand in relation to other items;
> 
>  * adding a relationship between one item and another does not change
> anything about the items.
> 
> I think all of these are important arguments, and each of them presents
> a strong case against making @instanceof behave in the way that you
> want, Ben. But I think the most significant is the last, which I
> mentioned earlier, and said I'd return to.
> 
> 
> ESTABLISHING A RELATIONSHIP SHOULDN'T
> CHANGE AN ITEM'S MEANING
> 
> So, to illustrate what I mean by saying that 'adding a relationship
> changes the meaning of the items', let's rewind to the beginning of my
> steps, and this time we'll use your rules instead of my 'old' RDFa
> rules. Also, since I'm not 100% certain that we agree on the meaning of
> the mark-up I've used as my starting-point, I've scoured all the
> discussions for a piece of mark-up that both sets of rules agree on, and
> found this (the initial comment is yours, just to put the mark-up into
> context):
> 
>   "And if you wanted to declare #me a foaf:Person, you would write it
> with two elements:
> 
>   <div about="#me" instanceof="foaf:Person">
>     <div rel="foaf:knows">
>       <span property="foaf:name">Ralph</span>
>     </div>
>   </div>"
> 
> I think we agree that in both sets of rules this snippet means:
> 
>   I am a person who knows something named 'Ralph'
> 
> As before I'll use @content to make things easier to read, giving us this:
> 
> ========
> <div about="#me" instanceof="foaf:Person">
>   <div rel="foaf:knows">
>     <span property="foaf:name" content="Ralph">
>     </span>
>   </div>
> </div>
> ========
> 
> Now, we're ready to proceed pretty much as before.
> 
> Let's say that Ralph knows Ivan; we know that Ivan can be identified by
> "http://www.w3.org/People/Ivan/#me", so it should be pretty
> straightforward to add @rel="foaf:knows", as follows:
> 
> ========
> <div about="#me" instanceof="foaf:Person">
>   <div rel="foaf:knows">
>     <span
>      property="foaf:name" content="Ralph"
>      rel="foaf:knows" href="http://www.w3.org/People/Ivan/#me"
>     >
>     </span>
>   </div>
> </div>
> ========
> 
> This inner element is quite a nice, self-contained block. At the moment
> it could be passed around from one document to another in its
> self-contained form:
> 
> ========
> <span
>  property="foaf:name" content="Ralph"
>  rel="foaf:knows" href="http://www.w3.org/People/Ivan/#me"
>>
> </span>
> ========
> 
> No matter where it appears it should mean the same thing--this is the
> 'cut-and-paste' point I made earlier.
> 
> But what if we want this self-contained block to also indicate that
> Ralph is a person? In earlier versions of RDFa we could have added a
> child <link>, as follows:
> 
> ========
> <span
>  property="foaf:name" content="Ralph"
>  rel="foaf:knows" href="http://www.w3.org/People/Ivan/#me"
>>
>   <link rel="rdf:type" resource="[foaf:Person]" />
> </span>
> ========
> 
> However, as we know, due to browser limitations we've had to remove this
> feature--the rule that allows '<link> and <meta> everywhere--from the
> current version of RDFa , although it is still present in XHTML 2's use
> of RDFa.
> 
> There was an additional design principle, though, that <link> as a child
> element was actually a longhand version of adding an attribute to the
> element, so the previous mark-up *should be* the same as this:
> 
> ========
> <span
>  property="foaf:name" content="Ralph"
>  rel="foaf:knows" href="http://www.w3.org/People/Ivan/#me"
>  instanceof="foaf:Person"
>>
> </span>
> ========
> 
> That's a slight diversion, but essentially my point is that since
> @instanceof is the renamed @class, and @class was always understood to
> be a shorthand for a child <link> element, then it is easy to see why
> the type and all predicates should be applied to the same subject. (And
> conversely, it is a very big leap to suggest that instead we should
> apply @instanceof to the _object_ rather than the _subject_, since there
> is nothing in the general architecture of RDFa that gives a precedent
> for that.)
> 
> So, your rules effectively suggest that @instanceof no longer applies to
> the subject of the element as it used to, but is now applied to the
> 'thing' being referred to, in this case Ivan. So if we wanted to
> indicate that 'the thing named Ralph' is a person, we  would have to
> wrap the mark-up in another element, and put the type onto that element.
> In other words, we would have to go from this:
> 
> ========
> <span
>  property="foaf:name" content="Ralph"
>  rel="foaf:knows" href="http://www.w3.org/People/Ivan/#me"
>>
> </span>
> ========
> 
> to this:
> 
> ========
> <span instanceof="foaf:Person">
>   <span
>    property="foaf:name" content="Ralph"
>    rel="foaf:knows" href="http://www.w3.org/People/Ivan/#me"
>   >
>   </span>
> </span>
> ========
> 
> You could say that this is not onerous, but it's not the extra mark-up
> that is the problem, it's the justification; we're asking authors to
> create an extra containing element, only because there is a resource
> predicate sitting on the element that represents the item that we want
> to set the type of. If the element didn't have a resource predicate:
> 
> ========
> <span
>  property="foaf:name" content="Ralph"
>>
> </span>
> ========
> 
> then we'd be allowed to add the type information to the same element as
> the one containing the literal:
> 
> ========
> <span
>  instanceof="foaf:Person"
>  property="foaf:name" content="Ralph"
>>
> </span>
> ========
> 
> In other words, there would be no need for the containing element.
> 
> In my mind this kind of restriction is a world away from the rules I
> showed at the beginning where all sorts of different pieces of mark-up
> represented exactly the same set of triples.
> 
> 
> MORE COMPLEX
> 
> Anyway, let's continue with this item--a self-contained item which is
> now 'a person named Ralph'. Given such an item, we'd expect to be able
> to put this anywhere we like, without any unexpected side-effects. So to
> continue our example, let's drop it into the the mark-up we were looking
> at earlier:
> 
> ========
> <div about="#me" instanceof="foaf:Person">
>   <div rel="foaf:knows">
>     <span
>      instanceof="foaf:Person"
>      property="foaf:name" content="Ralph"
>     >
>     </span>
>   </div>
> </div>
> ========
> 
> We now have:
> 
>   I am a person who knows a person named 'Ralph'.
> 
> Let's duplicate Ralph, change the name to Ivan, and paste this into the
> empty <span> element that represents Ralph:
> 
> ========
> <div about="#me" instanceof="foaf:Person">
>   <div rel="foaf:knows">
>     <span
>      instanceof="foaf:Person"
>      property="foaf:name" content="Ralph"
>     >
>       <span
>        instanceof="foaf:Person"
>        property="foaf:name" content="Ivan"
>       >
>       </span>
>     </span>
>   </div>
> </div>
> ========
> 
> At the moment there is no relationship between the two items, and all we
> have is this:
> 
>   I am a person who knows a person named 'Ralph'
> 
>   There is a person named 'Ivan'
> 
> This is pretty much the same as we had when building this up using my
> rules, and as before, we want to now continue on, heading for the same
> complex statement about Ralph, Ivan and Bill that we had above. So now
> we need to say that not only do 'I know Ralph', but also that 'Ralph
> knows Ivan'. We know that to express this relationship we need to use
> @rel="foaf:knows", so the question is quite simply, where should we put
> this attribute?
> 
> Since the predicate we are expressing ('foaf:knows') is a property of
> Ralph, then it would seem to make sense to add the attribute to Ralph's
> <span>:
> 
> ========
> <div about="#me" instanceof="foaf:Person">
>   <div rel="foaf:knows">
>     <span
>      instanceof="foaf:Person"
>      property="foaf:name" content="Ralph"
>      rel="foaf:knows"
>     >
>       <span
>        instanceof="foaf:Person"
>        property="foaf:name" content="Ivan"
>       >
>       </span>
>     </span>
>   </div>
> </div>
> ========
> 
> In the rules as they used to be, and as I showed above, this gives the
> desired result, with no side-effects. But with the rules you are
> proposing, Ben, although adding the @rel at this position creates the
> desired _relationship_ between the two items, it causes a number of very
> awkward things to happen.
> 
> 
> SIDE-EFFECTS
> 
> First, Ralph's @instanceof suddenly 'moves' from applying to him, to now
> applying to the bnode that the @rel creates. In other words, one moment
> Ralph is a person, the next he isn't, and all the author did was to try
> to place the item representing Ralph into a relationship with some other
> item.
> 
> Secondly, in your rules we are saying that 'Ivan is a person', twice.
> 
> Now you could argue that in order to create the explicit relationship
> that we want, we have to mark things up differently to this, according
> to your rules; after all, the fact that your rules don't give the same
> results as mine is the whole point of the discussion. :) So once again,
> to make things work we have to introduce an extra mediating element:
> 
> ========
> <div about="#me" instanceof="foaf:Person">
>   <div rel="foaf:knows">
>     <span
>      instanceof="foaf:Person"
>      property="foaf:name" content="Ralph"
>     >
> 
>       <span rel="foaf:knows">
> 
>         <span
>          instanceof="foaf:Person"
>          property="foaf:name" content="Ivan"
>         >
>         </span>
> 
>       </span>
> 
>     </span>
>   </div>
> </div>
> ========
> 
> Essentially we've had to add the extra element in between the two items,
> with @rel on it. Admittedly, as I said before, that's not an enormous
> amount of extra mark-up, but the real problem I have with this is that
> it is something that an author *must* do; it's not just a coding
> convention, or something that makes things a little easier to read, but
> is actually something that if the author _didn't_ do it, then their
> mark-up would mean something completely different to what they wanted it
> to mean.
> 
> 
> SIMPLE PATTERNS
> 
> But the worse thing about this is that it breaks the simple pattern that
> we have in RDFa, and it raises the question, why is @rel allowed to
> accompany its subject on statements like "I know a person named 'Ralph'":
> 
> ========
> <div about="#me" rel="foaf:knows">
>   <span
>    instanceof="foaf:Person"
>    property="foaf:name" content="Ralph"
>   >
>   </span>
> </div>
> ========
> 
> but it is not allowed to accompany its subject on the next statement,
> "Ralph knows a person named 'Ivan'"? The mark-up for that looks like this:
> 
> ========
> <div about="#me" rel="foaf:knows">
>   <span
>    instanceof="foaf:Person"
>    property="foaf:name" content="Ralph"
> 
>    rel="foaf:knows" href="http://www.w3.org/People/Ivan/#me"
>   >
>     <span
>      instanceof="foaf:Person"
>      property="foaf:name" content="Ivan"
>     >
>     </span>
>   </span>
> </div>
> ========
> 
> and although it works fine with my rules (we get "I know a person named
> 'Ralph' who knows a person named 'Ivan'"), when using your rules it is
> not intuitive at all why the @instanceof on the 'Ralph item' should
> suddenly 'jump' to begin applying to Ivan.
> 
> 
> PREDICATE PERMUTATIONS
> 
> To put this in a different way again, it's worth looking at what is the
> limit of what an element can express, as follows. Under normal
> circumstances, an element can obviously have a subject, but then on top
> of that, an element could have a maximum of three predicates, i.e., a
> literal, a resource, and an rdf:type. However, with your rules we have
> to effectively say that not all permutations are possible, and instead
> say that an element can only have a maximum of two predicates to
> accompany the subject. The permutations are as follows:
> 
>   * a literal on its own;
>   * a resource on its own;
>   * a type on its own;
>   * a literal and a resource;
>   * a literal and a type.
> 
> After that, when using your rules the remaining two permutations are
> unavailable:
> 
>   * a resource and a type;
>   * a literal, a resource and a type.
> 
> This is because the moment you add a predicate that takes a resource--as
> we did here by saying that Ralph knows Ivan--the type value no longer
> applies to the subject.
> 
> What I've tried to show in the way that the examples have gradually
> built up, adding a small piece of mark-up at a time, is that this
> restriction is unfair to authors; why should taking a self-contained
> item and adding a predicate to it change the meaning of that item?
> 
> 
> BUCKAROO
> 
> This 'flip/flop' behaviour reminds me of the children's game Buckaroo,
> where adding just one more item to the donkey's saddle can make it
> suddenly kick its hind legs in the air, throwing everything off its back
> that the players have added. :) In the case of your rules, adding @rel
> when @instanceof is already present, causes everything to be thrown into
> the air.
> 
> You might argue that I'm putting this a little strongly, and that it's
> not just _any_ relationship between two items that causes a problem, but
> rather it's the specific 'hierarchical' relationship that we've been
> using so far (i.e., where one <span> is inside another). But I'm afraid
> that's not the case, and even if we remove this hierarchy, the problem
> remains.
> 
> Let's rewrite the items for Ralph and Ivan so that they appear
> side-by-side, and let's also give Ivan the identifier that he uses:
> 
> ========
>   <span
>    instanceof="foaf:Person"
>    property="foaf:name" content="Ralph"
>   >
>   </span>
> 
>   <span
>    about="http://www.w3.org/People/Ivan/#me"
>    instanceof="foaf:Person"
>    property="foaf:name" content="Ivan"
>   >
>   </span>
> ========
> 
> Combining both pieces of mark-up, both your rules and mine would agree
> with the following interpretation:
> 
>   There is a person named 'Ralph'
> 
>   There is a person named 'Ivan', identified by the resource
> <http://www.w3.org/People/Ivan/#me>
> 
> Now, if we wanted to add the fact that Ralph knows Ivan, once again it
> would seem obvious to put the relationship information directly onto
> Ralph's <span>, as follows:
> 
> ========
>   <span
>    instanceof="foaf:Person"
>    property="foaf:name" content="Ralph"
>    rel="foaf:knows" resource="http://www.w3.org/People/Ivan/#me"
>   >
>   </span>
> ========
> 
> But now, once again, simply by expressing a relationship between two
> items, the rules you are proposing cause a change in the actual
> *meaning* of one of those items; in this case, Ralph is no longer a
> 'person', because the moment that you added the @rel/@resource
> combination, the @instanceof attribute 'flips' to applying to Ivan.
> 
> And note also that the Buckaroo doesn't just happen with the use of @rel
> and @instanceof. Let's return to the mark-up describing Ivan:
> 
> ========
>   <span
>    about="http://www.w3.org/People/Ivan/#me"
>    instanceof="foaf:Person"
>    property="foaf:name" content="Ivan"
>   >
>   </span>
> ========
> 
> We agree that this means:
> 
>   There is a person named 'Ivan', identified by the resource
> <http://www.w3.org/People/Ivan/#me>
> 
> Let's add that Ivan knows Ralph:
> 
> ========
>   <span
>    about="http://www.w3.org/People/Ivan/#me"
>    instanceof="foaf:Person"
>    property="foaf:name" content="Ivan"
>    rel="foaf:knows" resource="http://www.w3.org/People/Ralph/#me"
>   >
>   </span>
> ========
> 
> Again, we should agree that this means:
> 
>   There is a person named 'Ivan', identified by the resource
> <http://www.w3.org/People/Ivan/#me>
>   who knows something identified by the resource
> <http://www.w3.org/People/Ralph/#me>
> 
> Everything looks fine, so far...now try removing the @about value,
> perhaps to include this block somewhere else. Unfortunately, we once
> again get a flip/flop of meaning--a Buckaroo--since the mark-up without
> @about means something completely different:
> 
> ========
>   <span
>    instanceof="foaf:Person"
>    property="foaf:name" content="Ivan"
>    rel="foaf:knows" resource="http://www.w3.org/People/Ralph/#me"
>   >
>   </span>
> ========
> 
> In your rules Ben, this means:
> 
>   Something with a name of 'Ivan' knows a person identified by the
>   resource <http://www.w3.org/People/Ralph/#me>
> 
> With my rules, removing @about has no effect on the general meaning,
> which seems to me reliable and predictable--all removing the identifier
> does to our item is to remove the identifier. :) In other words, from this:
> 
>   There is a person named 'Ivan', identified by the resource
> <http://www.w3.org/People/Ivan/#me>
>   who knows something identified by the resource
> <http://www.w3.org/People/Ralph/#me>
> 
> we simply get this:
> 
>   There is a person named 'Ivan' who knows something identified by the
>   resource <http://www.w3.org/People/Ralph/#me>
> 
> 
> AVOIDING THE US OF ALL ATTRIBUTES AT THE SAME TIME
> 
> I know that you've suggested before that you wouldn't put all of the
> RDFa attributes onto one element in the way that I have done here, but
> I'm afraid I don't think that is a legitimate argument, for three
> reasons. First, as we just saw, there is actually no problem when *all*
> attributes are present, so the argument would need to be that we should
> avoid using 'most attributes'. :) But seriously, the problem in the last
> example I gave didn't arise until we went from using every attribute to
> removing @about. Likewise, in our earlier examples the problem arose
> when we tried to add @rel to an element that already had @instanceof,
> and so again was not a problem of having 'all' attributes.
> 
> The second reason is that the rules need to be consistent under all
> circumstances, and we can't simply say to people that they should avoid
> certain patterns because they don't behave in the way that they are
> expected to.
> 
> But the third reason is that I've not actually picked outlandish
> examples here--I've used the examples that you've suggested Ben, so as
> to create as much common terrain as possible. I hope you can see from
> these examples that having lots of attributes present is really not that
> unusual.
> 
> 
> CONCLUSION
> 
> I think the fact that you effectively came up with the same idea as
> chaining a 'second time' is pretty impressive! But I think that if we
> are to reintroduce it--which I'm mostly in favour of--we need to grab a
> couple of extra rules that we're currently missing.
> 
> I think it's worth looking at those in a separate thread, since I don't
> think it affects this discussion; at core, this thread is about whether
> @instanceof should apply to the object on an element, if present, and as
> I've tried to argue, I think it would be a big mistake if we made our
> attributes behave inconsistently in order to support that rule,
> especially when we can actually fulfill all of the use-cases that you
> (rightly) require.
> 
> Regards,
> 
> Mark
> 

-- 

Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf