Closed WeAreAVP closed 10 years ago
I guess the general question is "How much do we want to lock this stuff down?" I can see any number of places where we could restrict entries and then have no flexibility.
What is the use case to ever allow a valid PBCore 2.0 record to claim a schemaVersion that is not "2.0". This prevents the field from actually being trusted as an expression of which version of the schema it is. For instance a valid 2.0 record shouldn't ever say "2.1", right?
Sorry, I don't understand your point.
I may be confused as to what this attribute is meant to do. I understand that the user should have flexibility but this attribute appears to denote adherence to a particular version of the schema, but the user can not use this to express adherence with any version except "2.0". If the user enters the schemaVersion="1.1" then the document is invalid since the 1.1 XSD does not allow for the attribute. Having flexibility here would seem similar to allowing flexibility in the namespace attributes.
I'm getting back to this one and still having trouble understanding the use case to allow a user to express any string for the schemaVersion of a valid PBCore 2.0 record.
When should a PBCore 2.0 document not be schemaVersion="2.0"?
If the value (schemaVersion) that should declare the version of the schema can really be anything then I feel like we're back at running PBCore documents through validation against every version of the schema (or testing formatIdentifier placement) just to figure to figure one what version of the schema the document purports to be.
But what of version 2.1 that may only add/change an attribute?
then the changes to PBCore 2.1 xsd would also say schemaVersion must be 2.1.
Noted.
Re:
Is there any reason to allow any string expression in the schemaVersion attribute? Within a valid PBCore 2.0 XML should this always be "2.0".
To use MODS as an example again, if you have a MODS 3.3 record then the version must be expressed as "3.3".