Fix the type of the certifierCredential property

[llemeurfr]

certifierCredential "Identifies a credential or badge that establishes the authority of the party identified in the associated certifiedBy property to certify content accessible."

EPUB Accessibility 1.1 specifies that the type of certifierCredential is a string. There is no mention of a URL there.

This type is also visible in the example displayed in the Display Techniques for EPUB Accessibility Metadata.

But in the Display Techniques, a note indicates that "This metadata could be a simple text string in which case you would just display it, or it could be a URI to the certifier’s credential web page.". It is followed by different examples, including one with an image which is never defined (and relies on an undefined out of band distribution of logos ... an interoperability killer).

At the time we're trying to standardize the display of a11y metadata on library websites and in reading systems, and because this property is not the most important and publishers will have a hard time to understand it, having such a flexible type is in our opinion bad practice: publishers should not be left without precise indication and applications should not have to parse a string to decide how to display a metadata property.

We therefore ask for a stricter specification of this property type: plain string or URL, but not both.

[llemeurfr]

Plus, the cardinality of this property is unclear. In our (Readium folks) opinion it should be clearly expressed as 0..1.

[mattgarrish]

plain string or URL, but not both

We can formally recommend the value be a plain langugage description, but do we need to ban URLs? (Can we even testably ban them, except maybe absolute URLs?)

Another thought would be to require use of the link element if only a URL is available, as that would distinguish what you're encountering.

But are we expecting URLs from this field, or is the note just throwing a wide net to cover any possibilities?

In our (Readium folks) opinion it should be clearly expressed as 0..1.

Why can't someone have more than one certification? What if someone decides to certify publishers for European accessibility requirements, for example. Can a publisher not state they have both GCA and European credentials in their publication?

[mattgarrish]

Transferring this to the epub-specs repository, as any changes to the requirements and cardinality has to be done there, not in the CG.

[llemeurfr]

I agree that we cannot ban URL at a validation level, but we'd love to see the property specified as a plain language label.

For the cardinality, it can be discussed. But why would a certifier have several credentials? Note: the cardinality I'm speaking of here is the one of the credential vs its relative certifier.

Thanks Matt.

[mattgarrish]

But why would a certifier have several credentials

Credentials are just badges of the person who reviewed the publication, not something the reviewer is assigning to the content. It's like financial professionals listing all their certifications after their name.

It'd be like me saying I'm "Matt Garrish, GCA Certified, DAISY OK Certified, EAA Certified, ...". I can list all those in a publication to make me look more impressive as the person who has checked conformance.

I don't know how many credentials any publisher/reviewer will actually bother to get, but I'm hesitant to limit them to only one.

[clapierre]

Currently Benetech's GCA program is providing a URL to our GCA Credential Page where we have a "Mark/Stamp" logo displayed inside the certifiersCredential metadata.

I would love to see a solution here where if the certifier has a Logo/Mark/Stamp that could be displayed which would be a recognizable image something like the "CE" certification. Not sure if this could be part of the publication or not but this is a bigger discussion.

This way if we had the "Text" would be the alt text of the image, and then either a link to the image or embedded within the EPUB.

We had this issue where VitalSource Bookshelf were willing to display the GCA Logo but we didn't have a great way to do that without matching a specific URL inside the certifierCredential's metadata and providing our logo to them out of band, which I agree isn't ideal or scalable.

[mattgarrish]

I'm getting the sense we're not going to solve this in the next week, so maybe we should defer this issue?

It sounds like we have some work to figure out if another property is needed and/or whether the spec or the issuer of the credential should be the one setting the use expectations. Perhaps whatever we resolve on can be implemented in the guide as a way of incubating.

[llemeurfr]

If the certifier credential is a unique string, the certifier can send a complete info as "GCA Certified, DAISY OK Certified, EAA Certified". Easy to display.

If the cardinality of the property must really be multiple, this will make te life of library platform developer more complex (should it be displayed as a table ?).

Re. allowing recognizable images (whatever the solution is), I doubt that library managers would accept to insert in their web pages images they do not control (size, potential hacks), plus design a UI which can handle an undefined number of images (even if some sort of carrousel could work).

As much as we can, let's make the life of library platform developers and reading system developers less miserable :-)

[mattgarrish]

Bear in mind that restricting the property at this point isn't within our charter. We can loosen restrictions, but we can't add new restrictions that can invalidate content. I don't know how much the field is being used, but we've avoided other changes like this for the same reason of the unknown.

As for merging metadata, I'm not sure that's an ideal solution. We need to consider that this metadata is intended to translate between onix and marc, too, and having single text fields containing multiple values may not be desired for systems that expect formal metadata. It'd also put this field at odds with all the other metadata in the package. You can merge metadata if you only care about display, but I don't think we want to set that as a precedent here that it's what you must do.

I also thought Charles was wanting to use URLs to identify when to use an icon, not that you'd grab one from the URL, but I could be wrong.

Regardless, rushing changes has a way of coming back to bite us, but I'll defer to @avneeshsingh on whether he wants to take this up in the remaining four days next week. We are tight to the CR deadline now.

[clapierre]

At this point I agree let's leave this for now and address this in a future 1.2 version. Where we have potentially separate text string for the Name of the certifier's credential and a 2nd piece of metadata indicating its "Badge/Mark" image.

[llemeurfr]

For the record, Readium toolkits will process certifier credential as a string (which is consistent with the current draft of https://www.w3.org/TR/epub-a11y-11/#certifierCredential). In the Test Applications of the toolkits and in Thorium Reader, a URL will be displayed as-is, i.e. not clickable. These toolkits will consider 0..1 credential per certifier (we interpret the 0..n cardinality of the property as "N possible if there are N certifiers").