You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 11, 2019. It is now read-only.
The microdata model consists of groups of name-value pairs known as items.
Each group is known as an item. Each item can have item types, a global identifier (if the vocabulary specified by the item types support global identifiers for items), and a list of name-value pairs. Each name in the name-value pair is known as a property, and each property has one or more values. Each value is either a string or itself a group of name-value pairs (an item). The names are unordered relative to each other, but if a particular name has multiple values, they do have a relative order.
Q: What does "they do have a relative order" vs "are unordered" actually mean? Did anyone implement against this distinction?
A test case to explore could be based on something like:
The spec seems to say that the relative order of accessibilityFeature vs author on this Book is unimportant, whereas considering the values for accessibilityFeature, they are relative to each other; and considering the two authors listed, that ordering is also considered in some sense significant. For example, perhaps a later accessibilityFeature declaration overrides an earlier one; or perhaps a first-listed author is implicitly said to be a more significant contributor. Microdata delegates such details to vocabularies such as Schema.org. Schema.org says that it does not attach meaning at this level. Does anyone else?
So - I would like to explore clarifications in this area. Neither Schema.org nor the earlier datavocabulary.org vocabulary, assign semantics to this kind of property ordering. At Google we extract schema.org and datavocabulary Microdata into re-order-able triples / graphs; our parser currently assumes other uses of Microdata follow this pattern. I suspect @gkellogg and other parser writers may have implemented structures that represent the property ordering, but I do not know of anyone making use of such facilities.
I suggest that "but if a particular name has multiple values, they do have a relative order" may lack implementations beyond parsers i.e. vocabularies + publisher/consumer ecosystem. Is "parsers can handle this distinction" enough of an argument to preserve this aspect of Microdata, or can the spec be simplified in the light of experience here?
We might consider clarifying that the entire Microdata structure can be viewed as fully ordered as HTML, considered in the context of its life within a larger HTML document. This can be very important for use cases such as editors. However we might choose to say that order is not significant / meaningful when considering Microdata as a carrier of factual claims.
One way to state this idea would be to try to agree that any circumstances that are captured by the above test case ought to also be equally accurately described by the following test case (in which I have reordered everything):
IMO, only reasonable use for Microdata is schema.org, which currently does not order value output at all. Simplest thing is to say that multiple property values are unordered.
I was thinking to say something like “While it is harmless for e.g. authoring applications to make use of the enclosing documents natural ordering, publishers are cautioned that the output of microdata parsing does not preserve order unless dedicated structures (such as schema.org/ItemList or rdf:Collection) are explicitly used."
However, "the order of properties is not significant and authors must not rely on it being preserved"
works for me. Any serialization syntax by definition has an order, so maybe it needn’t be noted that using that order in editors is reasonable.
From https://w3c.github.io/microdata/#the-microdata-model
Q: What does "they do have a relative order" vs "are unordered" actually mean? Did anyone implement against this distinction?
A test case to explore could be based on something like:
The spec seems to say that the relative order of accessibilityFeature vs author on this Book is unimportant, whereas considering the values for accessibilityFeature, they are relative to each other; and considering the two authors listed, that ordering is also considered in some sense significant. For example, perhaps a later accessibilityFeature declaration overrides an earlier one; or perhaps a first-listed author is implicitly said to be a more significant contributor. Microdata delegates such details to vocabularies such as Schema.org. Schema.org says that it does not attach meaning at this level. Does anyone else?
So - I would like to explore clarifications in this area. Neither Schema.org nor the earlier datavocabulary.org vocabulary, assign semantics to this kind of property ordering. At Google we extract schema.org and datavocabulary Microdata into re-order-able triples / graphs; our parser currently assumes other uses of Microdata follow this pattern. I suspect @gkellogg and other parser writers may have implemented structures that represent the property ordering, but I do not know of anyone making use of such facilities.
I suggest that "but if a particular name has multiple values, they do have a relative order" may lack implementations beyond parsers i.e. vocabularies + publisher/consumer ecosystem. Is "parsers can handle this distinction" enough of an argument to preserve this aspect of Microdata, or can the spec be simplified in the light of experience here?
We might consider clarifying that the entire Microdata structure can be viewed as fully ordered as HTML, considered in the context of its life within a larger HTML document. This can be very important for use cases such as editors. However we might choose to say that order is not significant / meaningful when considering Microdata as a carrier of factual claims.
One way to state this idea would be to try to agree that any circumstances that are captured by the above test case ought to also be equally accurately described by the following test case (in which I have reordered everything):
These distinctions are a bit easier to state for languages that explicitly extract into atomic triples, but I think we can find a way.
Does anyone know of a use of Microdata which depends upon "but if a particular name has multiple values, they do have a relative order."?
/cc @tmarshbing @nicolastorzec @chaals, @betehess (and @pmika for old time's sake) for Bing, Yahoo, Yandex, Apple perspective on this.
The text was updated successfully, but these errors were encountered: