-
Notifications
You must be signed in to change notification settings - Fork 6
2020 02 06 METS & XLink
There are problems with the XLink schema that the METS schema references - specifically, that it is incompatible with the XLink schema published by W3C, which causes problems when METS is used together with schemas that rely on the W3C-published XLink schema.
We have decided to look into removing the dependency on the XLink schema, as XLink is not a widely used standard and PREMIS3 and EAD3 have both removed their dependencies on XLink.
Most of the discussion of the issue on this GitHub issue: https://github.com/mets/METS-board/issues/19
A couple other issues also touch on it:
https://github.com/mets/METS-board/issues/33 https://github.com/mets/METS-board/issues/30
See also the notes on the Trello board, for example https://trello.com/c/aeZ0iJ94/157-xlink-issues
- PREMIS 2 used only XLink simpleLinks; PREMIS 3 replaced the simpleLink attribute group with a single "simpleLink" attribute of type xs:anyURI
- EAD2002 had several elements that used the extended XLink attributes as well as several that used the simple XLink attributes. So far as I can tell (not being that familiar with EAD), EAD3 does away with the elements that used the extended XLink attributes. For simple XLinks, it retains those attributes, but in the EAD namespace.
- SVG2 (still a draft standard) deprecates xlink:href and xlink:title; xlink:href moves to a new 'href' attribute in the SVG namespace (https://www.w3.org/TR/SVG2/linking.html)
We discussed a couple possibilities for making a backwards-compatible change:
- just adding
xsd:anyAttras necessary to remove the dependence on the XLink schema, possibly with an auxiliary Schematron document for doing the XLink validation - adding same-named attributes in the METS namespace; deprecating the use of the XLink namespace and adding
xsd:anyAttras above but also declaring our own attributes with our own names
Neither of these options seemed appealing, and the original issue that was raised seems either to no longer apply or to apply only in very narrow cases.
Resolved that for now we will not make any changes to METS 1.x regarding XLink.
We agreed that if or when we produce METS 2, we will remove the dependency on XLink. The bigger question is what other issues to consider with respect to METS 2. We will review the previous work done on METS 2 and discuss at our next meeting whether we should move forward with work on METS 2.
For METS 2 there were two issues regarding XLink to consider:
At least in the existing registered METS profiles structLink is not widely used. There were likely uses in the past for archiving websites, but WARC is more common for that purpose now. However, there may be some cases where it is still useful.
For now, we will consider moving structLink to an optional extension schema and moving the extended XLink attributes to that schema's namespace. behaviorSec would also be a candidate for moving to this optional extension schema.
So far as we can tell none of the XLink attributes besides href are in use in any of the registered profiles for simple links. So, we would retain only an href attribute in the METS namespace (i.e. an approach like SVG2)
Could we simplify/flatten the METS structure somehow, reduce the number of elements? could some attributes be elements?
We need to think about the potential benefits of METS2 and focus on the goals of a backwards-incompatible schema. Easier to learn? Easier for humans to read? Easier to use for interchange between systems? Easier to use for either extension or restriction?
There was a paper on path to METS version 2 & objectives - presentation from Tom in 2010/2011? In 2015 - METS in RDF. These issues have been conflated in the past, but it is probably best if METS 2 and an RDF expression of METS should be separate things.
We could probably not get to a METS lite that would be a universal use for all implementors to date...
- Review the work to date on METS 2
- Discuss whether to pursue METS 2 at the next meeting (on Feb 27)