Add ID-Type for IIIF manifest

[rettinghaus]

As IIIF becomes so important for dealing with images, it would be good to have a special <idno> for storing the URL of the IIIF manifest, like
<idno type="URLIIIF">
or
<idno type="URLManifest">.

<idno type="URLImages"> is a bit too unspecific (and documentation could be improved).

[xlhrld]

Related to #43, so clearly +1 from me. Opting for URLIIIF rather than for the more generic URLManifest.

[wrznr]

idno@type should be made “open” in the sense that any value is allowed. There will always one more type.

[rettinghaus]

Let's agree on "semi-open".

[wrznr]

"semi-open"

Is this technically possible?

[rettinghaus]

Is this technically possible?

Yes, see https://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-valList.html.

[wrznr]

Yeah

Let's agree on "semi-open".

then.

[xlhrld]

Hm, semi-open may well lead to using different idno/@type for the same referencing system. Some coders might use URLIIIF, some might use UrlIIIF, some even IIIF only. This would clearly be a hindrance for (general purpose) DTABf processors and for interoperability. Currently, the meaning of idno/@type is well defined (if only in the docs) but coming across unknown types you will have to resort to guesswork.

I strongly opt for keeping the list closed but extendable by the DTABf maintainers. Additions of values for new referencing systems will never entail the need to adapt existing DTABf data (i. e. they will always be backwards compatible).

[wrznr]

Totally understandable.

extendable by the DTABf maintainers

But even for commonly agreed values like PPN, this does not seem to work. I.e. http://deutschestextarchiv.de/doku/basisformat/mdSdMsDesc.html does not have it while #68 says it should.

[rettinghaus]

This would clearly be a hindrance for (general purpose) DTABf processors and for interoperability.

I tend to disagree. The advantage of a semi-open list is, that in an editor (e.g. Oxygen) you'll still get the predefined values to choose from. With a closed list all non-standard values simply won't validate.

A schematron rule could be added to give a warning if none predefined value is selected.

[susannehaaf]

I think the list should remain closed for the reasons named above. But the final decision should be taken by the Steering Committee. For the time being, the value URLIIIF is now included in the respective value list of the DTABf schema (version 1.1.0).

[rettinghaus]

I'll close this issue, as the main part is resolved.
@wrznr should open another issue if it still should be discussed whether there should be open or semi-open lists.