14:20:38 <manu1> Gregg: schema.org is difficult w/o lists... linked list concept is very difficult... SPARQL deals w/ lists more intelligently. Also, I think people that do stuff w/ HTML expect document order. Complains people have about RDFa don't relate to processing steps... they relate to the complex rules of markup.

Gregg Kellogg: schema.org is difficult w/o lists... linked list concept is very difficult... SPARQL deals w/ lists more intelligently. Also, I think people that do stuff w/ HTML expect document order. Complains people have about RDFa don't relate to processing steps... they relate to the complex rules of markup.←

14:21:32 <manu1> MacTed: Difficulty in current use does not stand against something that makes later use better. People don't use ordered lists right now because they're a nightmare. If we make it easier to markup, more people will use them.

Ted Thibodeau: Difficulty in current use does not stand against something that makes later use better. People don't use ordered lists right now because they're a nightmare. If we make it easier to markup, more people will use them.←

14:22:56 <manu1> lindstream: There is a conceptual problem w/ lists in graph information theory - lists in JSON don't necessarily indicate order - the way the order is derived is not apparent. Most things are not naturally ordered, we use ordering based on the predicates in a set - ordering alphabetically or by date. There is a very distinct use of sets in RDF and the use of lists in RDF.

Niklas Lindström: There is a conceptual problem w/ lists in graph information theory - lists in JSON don't necessarily indicate order - the way the order is derived is not apparent. Most things are not naturally ordered, we use ordering based on the predicates in a set - ordering alphabetically or by date. There is a very distinct use of sets in RDF and the use of lists in RDF.←

14:23:18 <manu1> lindstream: This is not apparent to users. I support lists, but we should add something about this conceptual difference between sets and lists.

Niklas Lindström: This is not apparent to users. I support lists, but we should add something about this conceptual difference between sets and lists.←

14:23:47 <manu1> Manu: What state has to be stored? Does it work well with SAX-based processors?

Manu Sporny: What state has to be stored? Does it work well with SAX-based processors?←

14:25:01 <manu1> Gregg: There is extra state that is stored in the evaluation context... it could be passed through an incomplete triple mapping. Ivan's mechanism doesn't require that. State transfer is not particularly difficult to implement. The current algorithm is tail-recursive - this new version has a step after the tail-recursive mechanism. You may generate a list after the tail-recursive mechanism.

Gregg Kellogg: There is extra state that is stored in the evaluation context... it could be passed through an incomplete triple mapping. Ivan's mechanism doesn't require that. State transfer is not particularly difficult to implement. The current algorithm is tail-recursive - this new version has a step after the tail-recursive mechanism. You may generate a list after the tail-recursive mechanism.←

14:26:13 <manu1> Ivan: I did not think through the whole thing in this sense. I agree w/ Gregg. The way the algorithm is described now is pretty clear. You could pile everything up as you go. You don't need this last step at every element. At end of processing, you could generate the list triples. That may be better for a SAX-based implementation.

Ivan Herman: I did not think through the whole thing in this sense. I agree w/ Gregg. The way the algorithm is described now is pretty clear. You could pile everything up as you go. You don't need this last step at every element. At end of processing, you could generate the list triples. That may be better for a SAX-based implementation.←

14:33:22 <manu1> ShaneM: My question is wrt to backward compatibility - don't we have other features that screw w/ RDFa 1.0 - we have @vocab and @prefix... I think we don't have a proper announcement mechanism, we're going to have issues like this.

Shane McCarron: My question is wrt to backward compatibility - don't we have other features that screw w/ RDFa 1.0 - we have @vocab and @prefix... I think we don't have a proper announcement mechanism, we're going to have issues like this.←

14:35:05 <manu1> Ivan: The first issue that Niklas raised is a small thing - the attribute name that we should use - for historical reasons, we said @member... perhaps we should have @onlist? @onlist seems intuitive?

Ivan Herman: The first issue that Niklas raised is a small thing - the attribute name that we should use - for historical reasons, we said @member... perhaps we should have @onlist? @onlist seems intuitive?←

14:37:26 <scor> can't we choose a name now and eventually change it later? (it's just a string replace)

Stéphane Corlosquet: can't we choose a name now and eventually change it later? (it's just a string replace)←

14:37:42 <manu1> Gregg: I think I agree with Ivan - we have discussed this quite a bit, still some details - if there are issues with specific naming, we should proceed with something @onlist or @inlist, and we can change it at a later date. Let's get the processing steps down. Send a message to say that RDFa supports lists.

Gregg Kellogg: I think I agree with Ivan - we have discussed this quite a bit, still some details - if there are issues with specific naming, we should proceed with something @onlist or @inlist, and we can change it at a later date. Let's get the processing steps down. Send a message to say that RDFa supports lists.←

14:39:35 <manu1> lindstream: Should we support @rel and @property with @member - if nobody else has issues, I have no solution that works with subsequent related problems. Everyone should think about it and we should raise an issue if it becomes a problem.

Niklas Lindström: Should we support @rel and @property with @member - if nobody else has issues, I have no solution that works with subsequent related problems. Everyone should think about it and we should raise an issue if it becomes a problem.←

14:40:03 <manu1> lindstream: One thing that bugs me is that normally this...

14:49:54 <manu1> Ivan: This came up via Jeni and earlier with people realizing that @src creates a lot of problems in practice.

Ivan Herman: This came up via Jeni and earlier with people realizing that @src creates a lot of problems in practice.←

14:50:15 <manu1> Ivan: From a technical point of view, @src would behave exactly like @href and @resource... and not like @about.

Ivan Herman: From a technical point of view, @src would behave exactly like @href and @resource... and not like @about.←

14:50:46 <manu1> Ivan: Doing that in terms of changing the processing steps is very easy - 5 minutes of work.

Ivan Herman: Doing that in terms of changing the processing steps is very easy - 5 minutes of work.←

14:51:55 <manu1> Ivan: This is clearly a break in backwards compatibility - I sent around an e-mail asking if this would create a problem for people. I asked both Mark and Ben to comment, since they supported this the most strongly. All answers were that they agree with the change. The only thing that did come up show a number of tutorial that show how to use @src as @about - which is not good, but those...

Ivan Herman: This is clearly a break in backwards compatibility - I sent around an e-mail asking if this would create a problem for people. I asked both Mark and Ben to comment, since they supported this the most strongly. All answers were that they agree with the change. The only thing that did come up show a number of tutorial that show how to use @src as @about - which is not good, but those...←

14:52:08 <manu1> Ivan: unfortunately, I don't know if the charter allows us to make this change.

Ivan Herman: unfortunately, I don't know if the charter allows us to make this change.←

14:52:55 <manu1> Ivan: I propose that we discuss whether we agree to make this change - in case we agree, we don't implement it in the document, but we can go back to W3C Process Guardians to see if they have a major problem with this change and we'll go from there.

Ivan Herman: I propose that we discuss whether we agree to make this change - in case we agree, we don't implement it in the document, but we can go back to W3C Process Guardians to see if they have a major problem with this change and we'll go from there.←

14:54:16 <ivan> Backwards compatibility with RDFa 1.0 is of great importance. That means, in general, that all triples that are produced via the October 2008 version of RDFa, should still be generated in the new version. For each new feature, if there is doubt or a perceived problem with respect to this, the guideline should be to not include the feature in the set of modifications. The only minor feature the Working Group has identified and which may constitute a possible exceptio

Ivan Herman: Backwards compatibility with RDFa 1.0 is of great importance. That means, in general, that all triples that are produced via the October 2008 version of RDFa, should still be generated in the new version. For each new feature, if there is doubt or a perceived problem with respect to this, the guideline should be to not include the feature in the set of modifications. The only minor feature the Working Group has identified and which may constitute a possible exceptio←

14:59:19 <manu1> Manu: Couldn't we do that - if you have version="XHTML+RDFa 1.0" - @src is interpreted as it always has been... if it's not specified, or if it is 1.1, then use the new processing rules for @src.

Manu Sporny: Couldn't we do that - if you have version="XHTML+RDFa 1.0" - @src is interpreted as it always has been... if it's not specified, or if it is 1.1, then use the new processing rules for @src.←

15:00:05 <manu1> PROPOSAL: Change @src in RDFa 1.1 such that it is interpreted like @href and @resource (that is, it specifies an object).

PROPOSED: Change @src in RDFa 1.1 such that it is interpreted like @href and @resource (that is, it specifies an object).←