Repository navigation
Reading system requirement to resolve property datatype values #2317
Description
We've been having a discussion in the test repository about whether reading systems are required to process the compact URIs in attributes that accept a property datatype value.
My understanding since we created this framework in 3.0 is that it was optional and the rules are only defining how to resolve them for reading systems that want full URIs for verification. All the metadata that use these values are either unprefixed or have reserved prefixes you're not allowed to redefine so that there's never any ambiguity that needs resolving. The need to resolve prefixes only affects custom metadata introduced by the author.
The specification is a bit ambiguous about the requirement to process these values, however. Nowhere do we say outright that you must resolve all property datatypes, but there is a processing section that explains how you must process them. It says:
Reading systems MUST expand property values [epub-33] as follows:
My take on this is that it's more akin to: "If a reading system requires the full URI from a propery value, it MUST expand ..."
The requirement at the top of the processing section, however, says reading systems must support the vocabulary mechanisms. It is new to 3.3, though. If you go back in time, there isn't a requirement like that anywhere else.
But as I don't develop reading systems for a living, my understanding of the intent here may not match those who do. Do any reading systems support all the vocabulary mechanisms and expand all the property values, or is it more common to treat the values as tokens?
For example, do you take properties="nav" in a manifest declaration and expand the value to http://idpf.org/epub/vocab/package/#nav to determine the resource is the nav document?
If no one is expanding the values, we might want to consider lowering the support requirement to a "should" and clarifying that expanding property values is only required when a full URI is needed.
Activity
iherman commentedon Jun 17, 2022
The issue was discussed in a meeting on 2022-06-17
View the transcript
3. Reading system requirement to resolve property datatype values.
See github issue epub-specs#2317.
Wendy Reid: i attempted to write some tests about the property datatype values.
… these can appear in 2 places: OPF and content documents themselves.
… applies to any of the vocab, e.g. dc.
… the way it is currently worded in spec, we are expecting RS to resolve those prefixes to URLs.
… e.g. a11y would resolve to an expanded URL that takes you to a fragment.
… 'RS must resolve this to a URL'.
… but how to tell if RS is doing this in a test? Also, are RS really doing this? Because RS just needs to tell what kind of property it is.
Ivan Herman: it is clearly something that is sneaking into the spec from the RDFa world.
… which says that every property that you use must be identifiable by an URI.
… what these prefixes do is to abbreviate those URIs.
… I tried testing by saying that if RS really did this, then I would be able to use the full URI wherever I would use the prefixed version, and the behaviour would be the same.
… and all RS I tried failed on this test.
… so we have functionality here that is already heading towards under-implemented path unless we change it.
… essentially the whole prefix mechanism becomes unnecessary.
… i don't think the package document is suitable for RDFa anyway.
… maybe content document might be RDFa-able.
Matt Garrish: the package document was supposed to be RDFa-lite.
… so RDFa was an underpinning, but my understanding was that we were never requiring RS to process as RDFa.
… so if you wanted to treat them as just tokens, you could.
… to me i don't know if this requirement for RDFa processing should be a SHOULD or even a MAY.
… what we do have is the way that you should do the processing if you wanted to do that.
… I think we should make that distinction clear.
Ivan Herman: okay, so the operative thing is to make that clarification.
Matt Garrish: we've never had a statement that you must expand all data types. But somehow we say that you must support the mechanisms.
Ivan Herman: there are a number of places in the spec where we say "if there is no prefix, then use this URL".
… those statements would have to be clarified or changed then.
… so we wouldn't just be changing the vocab section.
Matt Garrish: i'd have to review the spec.
Matt Garrish: it should be like everything else in the spec i,e. 'if you are doing it, then here are the mechanisms'.
Wendy Reid: i think all the MUSTs are there, but they are all MUSTs.
… these are all meant to be testable, and i have yet to find a way to test them.
… so maybe we don't have an action today, other than giving mgarrish time to review?.