@xlink:href

[SJagodzinski]

Xlink: HREF

• remove xlink namespace and rename to @href
• accomponied by @lastDateTimeVerified, @linkRole, @linkTitle

Agreed in EAC-CPF and in EAD team to remove this attribute to simplify the schema, cf Berlin meeting:

Use @linkrole, @linktitle, and @href, from former XLink attributes and drop @actuate, @arcrole, @show.

Creator of issue

1. Silke Jagodzinski
2. TS-EAS: EAC-CPF subgroup
3. [email protected]

Related issues / documents

EAD3 Reconciliation

hypertext Reference

Summary: The locator for a remote resource in a link. When linking to an external file, href takes the form of a Uniform Resource Identifier (URI). If the value is not in the form of a URI, the locator is assumed to be within the document that contains the linking element.

Data Type: token

Context

Summary: Contains a URI, possibly relative, pointing to the related resource.

Description and Usage: The address for a remote resource. The xlink:href takes the form of a Uniform Resource Identifier (URI). While it is permissible to use a relative URI, and an absolute URI is recommended.

Data Type: anyURI

Solution documentation:

Rephrasing Summary and Description and Usage needed

May occur within: <contactLine>, <reference>, <representation>, <source>
Data Type: anyURI

[ailie-s]

What is the data type for @href? EAD3 uses token and EAC-CPF uses anyURI

[kerstarno]

Had a quick look through the EAD3 repository to see if there was anything that provided background to the use of token for @href in EAD3, but couldn't find anything.

The description of this issue here says: "change data type from anyURI to token", while the solution documentation says "date type: anyURI".

Can't remember if we specifically spoke about this, but it might be that in this case actually sticking with anyURI (and changing this accordingly for EAD during the revision) could make more sense.

[SJagodzinski]

As we adopted @href from EAD, we are going to use token.

Might be changed during the Call for Comments period, if necessary.

[fordmadox]

@SJagodzinski I would prefer to keep those defined as "anyURI" instead, and not follow what EAD3 did.

This keeps us in line with other standards like TEI, XHTML, etc.

[fordmadox]

@tcatapano: Do you recall why EAD3 went with "token" when defining @href? (e.g. https://github.com/SAA-SDT/EAD3/blob/814ff500b9e866962a98e9d68f876dd9ad2c9988/redesign/ead_revised_defs.rng#L2733-L2737).

[SJagodzinski]

@fordmadox : Due to alignment with EAD3. I assume that EAD revision team had an idea behind this data type.

We can discuss these details during the Call for Comments period, but to finalise the draft for the Call for Comments, I try to freeze a status. No time and need to discuss the attribute data types at this moment, I think.

[fordmadox]

Let's keep the @href datatype as anyURI for the time being, then. I've no clue why it should differ in datatypes from the other attributes, like valueURI, etc. (I have already changed localType to 'token', though, as requested, which aligns things with EAD3, and should not impact the migration process, I don't expect).

[ailie-s]

Tag Library Text:

Summary: The address for a remote resource. @href takes the form of a Uniform Resource Identifier (URI).
Data type: anyURI

[kerstarno]

Tested as part of Schema Team's schema testing:

• @href is an optional attribute in <representation>, <source>, <reference>, <contactLine> and <setComponent>
  • @ailie-s Not sure, if you wanted to list the potential parent elements for @href. If yes, and depending on the decision of keeping or removing <alternativeSet> and its sub-elements, <setComponent> would need to be included next to <contactLine>, <reference>, <representation>, and <source>
• It is accompanied by @lastDateTimeVerified, @linkRole, and @linkTitle
• Its data type is anyURI

The above applies to both schemas, RNG and XSD.

The attribute is ready.

[tcatapano]

@tcatapano: Do you recall why EAD3 went with "token" when defining @href? (e.g. https://github.com/SAA-SDT/EAD3/blob/814ff500b9e866962a98e9d68f876dd9ad2c9988/redesign/ead_revised_defs.rng#L2733-L2737).

@fordmadox: IIRC -- and @rockivist could confirm or refute -- the rationale was for the general schema to err on the side of permissiveness while allowing stricter validation through subsetting. In the case of @href I think there was some concern that not all actually existing, in the wild URL's will pass anyURI validation (especially if copied and pasted without subsequent url encoding). For example, one comes across DOI urls overloaded with metadata and offending characters from time to time. See: https://doi.org/10.3161/1733-5329(2007)9[161:LTDSDO]2.0.CO;2 (see also other articles for this journal: https://bioone.org/journals/acta-chiropterologica/volume-9/issue-1)

I did run a test against 79K+ @href values from <dao>s extracted from the Archivegrid corpus circa 2014 and none failed XSD validation as anyURI. So whatever the rationale, in practice it seems like using the datatype is very unlikely to cause many problems.

Hope this helps.

[rockivist]

@tcatapano When @fordmadox asked me about this I couldn't recall the details, but now that you say it, I'm certain that your recollection of the justification for using token rather than anyURI for href in EAD3.

FWIW I think changing to anyURI would be fine.