Some concerns about the list implementation in RDFa 1.1

Jeni, all,

during the last telecon I raised some questions regarding the current
suggestion of using @member for lists in RDFa 1.1.

1. I wonder whether "member" is an appropriate name for the attribute
triggering list processing. My concern is that it may not fully convey the
specific list nature of the feature (since "member" conceptually also
applies to the default "set" nature). I'd suggest e.g. "listitem" or
"inlist".

2. Another concern is about backwards compatibility. If @member is not
interpreted by a processor, it would instead add triples the "normal" way
– i.e. produce different data. This may be bad, or it may be viewed as "at
least you get something". We should evaluate that.

3. I'm also slightly uncomfortable with the use of an "empty" attribute
(unless I'm "thinking in HTML5"). We briefly discussed the possibility of
combining @rel/@property with @member, making the usage more compact (and
solving the backcompat issue). There are some problems with that though. One
concern was about what should happen if a combined attribute is present
*alongside* a @rel or @property. Another was that it wouldn't follow the way
RDFa currently works if such a combined attribute we're to work with
references if @href/@resource is present and otherwise with literals.
(Although there has been talk about the relative merit of letting @property
work like that, we have not done this yet, and may decide not to. *If* we
were to do that, it might be valuable to have @member work similarly.) I
have not been able to come up with another solid solution to these things
though, so unless others also have concerns with the empty form, I won't
object further.

(I can even imagine that @member could default to list processing, but if
given a value of "seq", "bag" or "alt" it could trigger support for those
containers instead. I'm not particularly in favor of that personally, but
the option should be considered.)

Best regards,
Niklas