Use of LC xlink instead of w3c xlink fails in mixed validation. Mixup/clashes in schema definitions.

[klindt]

ALTO (also true for MODS, METS and EAD) uses a LoC version of xlink.xsd (http://www.loc.gov/standards/xlink/xlink.xsd) but with a w3c namespace (https://www.w3.org/1999/xlink.xsd). When validating mixed xml we prefer to use the w3c version of the schema but this fails some cases of LoC standards and using the LoC version does'nt validate other schemas.

Could ALTO be updated to either use w3c xlink.xsd or replace xlink: with something like simpleLink like in the PREMIS3 schema?

Old discussion here: https://listserv.loc.gov/cgi-bin/wa?A2=ind1110&L=MODS&D=0&P=9585

[artunit]

I don't see a problem with doing this but will bring it forward at our next Board meeting, which is tentatively set for 2021-02-25. Thanks for raising this.

[jukervin]

METS is also planning to stop referenceing Xlink.

mets/METS-board#38

[artunit]

Thanks for this example. I think this is a good model to follow and could be part of the next schema revision.

[artunit]

As per the 2021-04-29 Board Meeting, the ALTO schema will be modified to change this line:

schema/v4/alto-4-2.xsd

Line 443 in 831adab

<xsd:attributeGroup ref="xlink:simpleLink"/>

to:

<xsd:attribute  name="simpleLink" type="xs:anyURI"/>

as done in Premis-v3-0 . The reference to the XLink namespace and schema will also be removed.

[cipriandinu]

I have some comments on this proposal
The proposed change:

<xsd:attributeGroup ref="xlink:simpleLink"/>

With

<xsd:attribute name="simpleLink" type="xs:anyURI"/>

as in Premis 3.0, I think that this is not an accurate replacement. Mainly this reduce xLink:simpleLink group of attributes (containing several attributes) to xLink:hRef attribute, and renames it using the group name. More accurate would have been to replace

<xsd:attributeGroup ref="xlink:simpleLink"/>

With

<xsd:attribute name="hRef" type="xs:anyURI"/>

(if we only want to keep only that, not the entire group).

Even this I think is a better replacement, the solution from METS change proposal (the one Jukka outlined) I think is the complete solution – please see bellow changes based on this recommendation. We can use also the Premis 3.0 proposal (original from this post, or the version I have mentioned), but I would change it to the more accurate version, similar with METS proposed changes.

Replace:
<xsd:attributeGroup ref="xlink:simpleLink"/>
with
<xsd:attributeGroup ref="simpleLink"/>

Add (optional, if we still want to consider valid attribute former xLink:simpleLink, when namespace is used explicit)
<xsd:anyAttribute namespace="##other" processContents="lax"/>

Add definition of simpleLink attributes group (we only need this, since in ALTO only simpleLink is used, no other attribute groups from xLink):

<xsd:attribute name="href" type="xsd:anyURI"/>
<xsd:attribute name="role" type="xsd:string"/>
<xsd:attribute name="arcrole" type="xsd:string"/>
<xsd:attribute name="title" type="xsd:string"/>
<xsd:attribute name="show">
	<xsd:simpleType>
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="new"/>
			<xsd:enumeration value="replace"/>
			<xsd:enumeration value="embed"/>
			<xsd:enumeration value="other"/>
			<xsd:enumeration value="none"/>
		</xsd:restriction>
	</xsd:simpleType>
</xsd:attribute>
<xsd:attribute name="actuate">
	<xsd:simpleType>
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="onLoad"/>
			<xsd:enumeration value="onRequest"/>
			<xsd:enumeration value="other"/>
			<xsd:enumeration value="none"/>
		</xsd:restriction>
	</xsd:simpleType>
</xsd:attribute>
<xsd:attributeGroup name="simpleLink">
	<xsd:attribute name="type" type="xsd:string" fixed="simple" form="qualified"/>
	<xsd:attribute ref="href" use="optional"/>
	<xsd:attribute ref="role" use="optional"/>
	<xsd:attribute ref="arcrole" use="optional"/>
	<xsd:attribute ref="title" use="optional"/>
	<xsd:attribute ref="show" use="optional"/>
	<xsd:attribute ref="actuate" use="optional"/>
</xsd:attributeGroup>

What would be the preferred version?

[artunit]

I happy to follow @cipriandinu on this, the solution from METS change proposal as outlined sounds like a good direction. I will add a discussion label to this issue.

[cipriandinu]

On last board meeting discussions we figure out that xLink is not really used in practice. It appears as attribute of BlockType, to indicate links from one particular block to another resource, probably an external one. Usually this mechanism is used in METS to reffer an ALTO block (and in general to identify an external file into FLocat, mptr, etc tags), but inside ALTO, specially as attribute of BlockType does not really makes sense. Due to that an alternative solution that could work is to remove this attribute from BlockType in 5.0. Please vote as ACCEPT if you agree, or in case you know some use cases in practice, please add the info to this topic, so that we reconsider this.

[ntra00]

ACCEPT

[cowboyMontana]

ACCEPT

[callylaw]

ACCEPT

[cipriandinu]

Based on last board meeting, in case the final decision would be to completely remove xLink references we should announce in schema 4.4 documentation this intention (mark it as obsolete and announce future removal)

[cneud]

Based on last board meeting, in case the final decision would be to completely remove xLink references we should announce in schema 4.4 documentation this intention (mark it as obsolete and announce future removal)

+1 and ACCEPT

[cipriandinu]

Looks like in METS v2 METS Board also intends to remove xLink - see https://github.com/mets/METS-schema/blob/mets2/METS2.md

[Haighton]

ACCEPT

[JLoitzenbauer-CRKN]

ACCEPT

[c-sebastien]

ACCEPT

[rajubln]

ACCEPT

[cipriandinu]

In order to solve this issue a new branch was created (issue-67) from (version5.0) branch (generic one for 5.0 changes). Please check the changes and if you think it completely covers the topic, please vote with ACCEPT, else add you comments and modify schema if needed

[cipriandinu]

ACCEPT

[JLoitzenbauer-CRKN]

ACCEPT

[cneud]

ACCEPT

[ntra00]

ACCEPT

[hanyelsawy]

ACCEPT

[rajubln]

Accept

[jukervin]

Accept

[JLoitzenbauer-CRKN]

Accept

[splet]

ACCEPT

[JLoitzenbauer-CRKN]

Accept

[c-sebastien]

Accept

[callylaw]

Accept