Introduce datatypes for CssSelector and XPath

[danbri]

Suggestion building on (experience implementing) the xpath/css mechanism from SpeakableSpecification ie. #1389

Context: http://pending.schema.org/SpeakableSpecification was added in v3.2 (including 'xpath' and 'cssSelector' properties which expect 'Text' values), in "pending review" area of schema.org.

Proposal:

• XPathType (new datatype, subtype of Text), "Text that encodes a W3C XPath".
• CssSelectorType (new datatype, subtype of Text), "Text that encodes a CSS selector".

Motivation: to allow applications to offer more accurate validation, error checking, and automated coercion to other representations of these datatypes. Also to help decouple the generic aspects of the SpeakableSpecification proposal from its Text-to-Speech specifics.

Currently http://pending.schema.org/xpath expects a value of type Text; if these datatypes went through, it could expect XPathType instead (and the schemas would declare this to be a specialization of Text). Similarly for cssSelector.

Potentially there could be subtypes tied to versions of Xpath and CSS. My understanding is that XPath is more explicitly versioned than CSS, perhaps Xpath explicit versions would be more necessary? e.g. https://www.w3.org/TR/xpath-30/#nt-bnf

/cc @chaals

[chaals]

At a technical level this makes sound sense, but to make it work we need to have really good documentation, examples, and probably a place where people can test and get a sense of what it does by playing - and a big warning if they are doing it wrong.

[danbri]

@chaals thanks. any sense for the versioning aspect? in terms of making a viable validator/checker, there's the "does this look like the right kind of formatted string" aspect, ... but then there's the "which bits of some HTML document does it match" side too. I am not an expert but I guess there are xpath expressions that would match different bits of doc depending on the assumed xpath version?

[chaals]

I'm not an xpath expert either... I'll ask one if I find one. But my rough sense is that we should leave out the version thing unless there is a screaming need for it. As far as I understand, the versions are generally not going to result in a particular xpath pointing to a different part of the same document just because it uses a different version.

[darobin]

I can't think of XPath constructs that would match different things depending on the XPath version in use. If you use constructs from an unsupported version, most likely you will just get an error. This is also the behaviour you are likely to get from CSS Selectors.

I don't think specifying the version is really useful. For the use case at hand, v1 should be more than enough. It's also the only version you're likely to find in a browser or in JS. There are some considerations applying to usage of XPath in HTML that might be good to link to.

[danbri]

Thanks @chaals @darobin - yeah I was leaning towards implying latest/v3 but not creating types for all 3. But point taken re v1 and JS.

Ping @tmarshbing @scor @nicolastorzec @rvguha @vholland @tilid

Any objection to my going ahead and sketching this out within the context of pending.schema.org?

I feel it could give us a useful primitive for making stronger links between schema.org data and the browser environment / non-schema.org web content.

[chaals]

sketch away :)

[darobin]

I would suggest implying (or even specifying) v1. Switching to a higher version later if needed will be painless, which is not true of the reverse.

[nicolastorzec]

Sketch away.

[danbri]

Ok, I'll make a pass at this. cheers...

[danbri]

This is still in Pending. The nature of the (fairly well adopted) Speakable specification is such that these terms are only used to define the vocabulary deployed for SpeakableSpecification, and won't themselves be appearing in actual markup. Since speakable stuff went into the core, I think these ought to accompany it. Any objections?

/cc @RichardWallis

[RichardWallis]

@danbri
See no reason not to move to core.
However, if you then view the list of sub-datatypes of Text, htmlText seems to be an obvious absentee.

[github-actions]

This issue is being tagged as Stale due to inactivity.