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.
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:
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 tohttp://idpf.org/epub/vocab/package/#navto 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.