Clarify syntax of metadata terms.

[jasonjgw]

I think the syntax of the metadata property values could be clarified further. Based on reading the draft, the syntax appears to be case-sensitive identifier, followed by zero or more optional extensions, where an optional extension consists of a slash ("/") followed by an identifier.

Section 4.2.4.3 (Braille) presents a series of extensions that make the most sense if more than one can be specified. However, I didn't notice a formal definition of the syntax If only one extension can be specified, then this would be an issue in the braille case, as a document can conform to multiple braille codes (e.g., "braille/grade2/math").

My suggestion would be to specify the general syntax early in the document, and to define what an "extension" is.

It should perhaps also be specified that processors should ignore values or extensions that they don't recognize (but they may issue a warning), unless of curse they are validators.

[mattgarrish]

This looks like a duplicate of #11

Back when we first developed this vocabulary, the recommended method for extending things in schema.org was through slashes. They've since dropped that model, so our continued use of it is problematic.

[jasonjgw]

This issue is closely related to, but distinct from #11. Whereas #11 questions the syntax, this issue suggests that it should be clearly and formally defined in the specification (preferably early).

[mattgarrish]

Sure, but until it's clear what we're using moving forward, it's not helpful to promote the slash syntax as though it's something authors should be using.

What we can do for now, though, is note where the syntax came from, referencing the old extension page, with a caution that it may change in the future.

I'm personally not convinced extensions are even a good idea, as all they do is lead to interop problems. I suspect that's also why schema.org has been moving away from them. If we need more precise values, let's mint new values, or figure out what is better written out in a summary because it's getting too deep into details, rather than rely on authors slapping on extensions, possibly of their own making.

[jasonjgw]

There is also text (in the braille section, if I remember rightly) which implies that an open-ended and unspecified set of extension values is acceptable. I think that's problematic for interoperability reasons, so regardless of whether the syntax is changed, defining all of the allowed values should be a requirement, in my view.

[mattgarrish]

There is also text (in the braille section, if I remember rightly) which implies that an open-ended and unspecified set of extension values is acceptable.

Right, that's a big part of the problem. It's basically left to the processing agent to know how to split the values apart and what sense to make of them. If there were a recognized and supported way of doing this for schema.org, that would be a different story. But there isn't, so the randomness of being able to use slashes on any term is problematic as there's no guarantee a processor will do anything but treat the value as a simple string.

We're not even consistent ourselves in applying the slash syntax. The "on visual" terms for access modes are effectively extensions of "visual" that don't rely on slashes.

Add to it that any term can be extended by a slash, not just the ones we list some possible extensions for, and there's no accounting for what values could be encountered. Plus you can keep joining refinements with slashes, so for braille you could have braille/bana/grade2/math/music, with any permutation being valid.

It would be simpler to process these if they were separate terms, like braille_bana, braille_grade2, etc. Couple that with a recommendation that if you're going to use extended values always include the base value (braille in this case) to allow basic matching.

That would be a path to allow a more useful extension pattern, anyway, if we want to keep a clear method for authors to introduce new values.