Open koit opened 5 years ago
I really like this solution to have the namespace and schema location requirements stand out along with the other requirements.
I am not sure about the renumbering of the other requirements though. I think the requirement-IDs need to be stable.
We dont rename ID's for the requriments at this stage.
I'll look into this. But if we go down this route of adding the namespaces as requirements the whole XML-header also needs to be a requirement.
Just to say that I agree with @PhillipTommerholt & @karinbredenberg, we now need to resist the temptation to renumber requirements. Permanent IDs (and by extension URLs) for requirements is more important than sequentially numbered requirements. Once anything new arose we were always going to loose neat numbering.
Sorry, I didn't know it was too late. My assumptions were:
There will always be unpredictable additions, so we should come up with a long-term solution. We are wrestling with the classic problem of semantically loaded (or natural) IDs, which can be solved with surrogate (or synthetic) IDs, or with something in between. The semantic load in our case is the logical order of the rules.
I see three solutions:
CSIP1.1
, CSIP1.2
, CSIP1.3
, CSIP2.1
), new requirements are added to the end of the appropriate chapter. An ID once assigned stays the same permanently (unless the chapters are restructured);CSIP-N2
, CSIP-05
, CSIP-AA
, CSIP-Z9
). Keeping it case-insensitive would give us a pool of 36^2 = 1296 IDs.Its a decision made by the DILCIS Board. We've had decisions and will look up the result and post it here.
(The ID's are xml:ID's which also gives restrictions in the naming of them.)
Nice sum up from the discussion we had in A3 last time, Koit 👍
Discussed both points with @karinbredenberg.
Regarding additional requirements. We're in danger of writing our own version of W3C XML requirements here. Would a better solution (or compromise depending on your POV) be to make explicit recommendations with references to authoritative documentation to address this issue?
Regarding requirement numbering: Under consideration, can see the strengths of keeping related requirements together. Time is against us here but that's got to be balanced with the reality that this is our only chance to make such a change. :+1: from me for changing but will depend on pragmatic reality.
Do take into account the presence of CSIPExtensionMETS
which isn't mandatory but IS required for a valid IP.
Am now wondering if been explicit in text regarding XML schema validation been part of any validation process. This would at least imply inclusion of the minimal schema set required for a "schema valid" XML document. This wouldn't require a new requirement necessarily but some better explanatory text that highlights use of the main schema and vocab documents.
Section 5.3.1 is pretty explicit about namespacing and schema validation will take care of other parts. I'm not against adding specific requirements but only if they can be tested via schema/schematron. I'd suggest we bump this forward but with a specific aim of developing automated tests. If we can then we add the requirements, which won't break backward compatibility as the requirement currently exists, it's just not explicitly stated/enforced. A test may not be as easy to come up with as it appears: https://stackoverflow.com/questions/35467330/xpath-in-schematron-how-to-determine-if-an-xmlns-attribute-is-present-on-a-node
This needs moving to the validator issue list as it's now about testing rather than the specification.
The current version of 5.3.1. Use of the METS root element (element mets) states:
These are concrete MUST rules, so they should have their own named requirements (and the lines above should be removed from the intro of Chapter 5.3.1.):
mets/@xmlns
mets/@xmlns
attributes. A valid CSIP METS.xml document needs at least the declarations forMETS
,CSIPExtensionMETS
andXMLSchema-instance
, and in most cases alsoxlink
.MUST
mets/@xsi:schemaLocation
mets/@xsi:schemaLocation
attribute.The schema files are needed at the time of validation, so they should be stored at a location accessible throughout the lifetime of the IP, or included in the
schemas
folder. In the latter case, it is recommended to link to the schemas using the relative path (e.g.schemas/mets.xsd
).Note 1: it is assumed here that
xsi
has been declared as the prefix forXMLSchema-instance
namespace, but this choice is not mandatory.Note 2: The xsd file location for
XMLSchema-instance
does not have to be shown because of its special, built-in status.MUST
Side effect: the numbers for current CSIP7 to CSIP112 will need to be incemented by 2.
Related to #228.