-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Common approach to XLink namespace #1
Comments
Conversations so far have reiterated the argumentation followed during the EAD revision, that inclusion of namespaces introduce "onerous and needless complexity [...] when processing XML" (quote from Preface to EAD3 Tag Library). In addition, the use of XLink in general seems to be declining. Furthermore, the point has been made that, if EAC-CPF and EAD3 were to use XLink, this should mean an actual implementation of these attributes as set out in XLink rather than e.g. implying restrictions (as done currently with xlink:type only allowing the value "simple"). |
Inclination to NOT include XLink namespace anymore. Next steps:
|
I've linked this issue to the according conversation within the EAC-CPF subteam. |
See EAC-CPF team decision in our issue. Removing is agreed, but make sure to keep linking functionality in the schemas with the same language. Also agreed on your next steps. |
Requirement to pick up on decision at EAC-CPF team. Similarly to what's been said for the XML namespace (#2), terminology might be useful to discuss jointly with EAD and EAC-CPF teams for alignment. |
While EAC-CPF uses attributes from the XLink namespace (xlink:actuate, xlink:arcrole, xlink:href, xlink:role, xlink:show, xlink:title, xlink:type), EAD3 has taken the decision to move away from XLink and to use its own version of these attributes (actuate, arcrole, href, linkrole, linktitle, show).
The text was updated successfully, but these errors were encountered: