- From: Dan Brickley <danbri@danbri.org>
- Date: Mon, 18 Jun 2012 18:46:15 +0200
- To: Jason Douglas <jasondouglas@google.com>
- Cc: Adrian Giurca <giurca@tu-cottbus.de>, Egor Antonov <elderos@yandex-team.ru>, Peter Mika <pmika@yahoo-inc.com>, Ivan Herman <ivan@w3.org>, "public-vocabs@w3.org" <public-vocabs@w3.org>, "Martin Hepp (UniBW)" <martin.hepp@ebusiness-unibw.org>, Ramanathan Guha <guha@google.com>, Jeni Tennison <jeni@jenitennison.com>
On 18 June 2012 17:44, Jason Douglas <jasondouglas@google.com> wrote: > That's not just a token list... it's an ordered token list. > You're privileging the first token as the "frame" as Martin calls it. In > the case of a token list for itemprop there's no order dependance (and I'm > guessing that's the reason itemtype is the way it is in the spec). I'm ok with having a privileged role for the first token; Microdata needs something like this, since it thinks of the properties as being set by types, in contrast to RDF's more statement-oriented model. There's also a sense in which schema.org descriptions prioritize schema.org types that suits this constraint. We don't mind things-that-look-like-types from other namespaces being mentioned but currently the schema.org partners only collectively say that they "understand" stuff from schema.org's own namespace. The 'additionalType' design + phrasing, and the 'add it to end of space-separated list' approach, both work from that perspective. So - if we went for the 'tweak Microdata' approach, what if anything might break in practice? Dan
Received on Monday, 18 June 2012 16:46:45 UTC