xmllint complains about objectxmlwrap in xsd

[tcatapano]

ead3.xsd:1397: element complexType: Schemas parser error : complex type 'objectxmlwrap': The content model is not determinist. ead3.xsd:1402: element complexType: Schemas parser error : complex type 'e.anyname': The content model is not determinist.

[tcatapano]

same with libxml in oxygen (same library?). Not a problem sith Saxon-EE and Xerces/Jing.

[ottosmops]

I have the same problem. I can validate with Oxygen, but when I validate via libxml I get the same error.

[shsdev]

Same issue using python lxml.

[tcatapano]

Going to create a branch to investigate an alternative which will satisfy libxml.

[shsdev]

Just to let you know that if I comment out the <xs:any namespace="##local" processContents="lax"/> line the error is not thrown:

`

`

[tcatapano]

This should be fixed now in branch issue_#499. Need to test some more.

[rockivist]

@tcatapano This is awesome. Thanks so much. I'll give it a look in Oxygen, but I'll leave the libxml testing to you and others.

[rockivist]

In ead3.xsd, getting the following error

conflicting ID-types for attribute "id" of element "quote" from namespace "http://ead3.archivists.org/schema/"

I'm sure you've seen this. It's caused by the <attribute a:id="a.anyName"> on line 2715. I can't say whether this is a real problem or not.

In practice my monster testing instance validates fine if I drop an entire ead instance into the revised objectxmlwrap. Tried it in both <source> and <relation>. If I put a non-root EAD element in - say just a c02 - it throws an error unless I add the EAD namespace declaration. This is the expected behavior according to the tag library. So everything seems good in practice.

FWIW I'm testing in Oxygen Editor 18.1 for testing. I'm afraid testing against different libraries is up to you.

[tcatapano]

Need to test using ruby/nokigiri and python/lxml

[tcatapano]

Ive regenerated ead3.xsd and now it seems to work with xmllint. Have to regenerate undeprecated version

[tcatapano]

generated ead3_undreprecated xsd, but it is failing to validate under libxml. No idea why. Will have to investigate further. PITA

[fordmadox]

@tcatapano any updates on the ead3_undeprecated validation issue? I'm hoping to dig back into this next week so that we can get another candidate release out soon for 1.1.

[tcatapano]

@fordmadox I'll look into today and report back

[tcatapano]

@fordmadox: Ive looked into it and I'm still baffled as to why the undeprecated xsd is not being generated from ead3_undeprecated.rng with the correct e.anyname model. I can explain further and continue to explore, but I'm not sure at this point a technical solution is more important than a strategic and economic one.

If, as I recommend and hope, the undeprecated schemas will not be supported beyond the 1.1 release, I propose that we take a blunt approach and simply manually correct the model for e.anyname in the ead3_undeprecated.xsd from:

  <xs:complexType name="e.anyname">
    <xs:choice>
      <xs:any namespace="##other" processContents="lax"/>
      <xs:any namespace="##local" processContents="lax"/>
    </xs:choice>
  </xs:complexType>

(at: https://github.com/SAA-SDT/EAD3/blob/41df34c10780aa32afcc1bd59028ecb4a58af713/undeprecated/ead3_undeprecated.xsd#L170)

to

  <xs:complexType name="e.anyname">
    <xs:sequence>
      <xs:any processContents="lax"/>
    </xs:sequence>
  </xs:complexType>

(as at: https://github.com/SAA-SDT/EAD3/blob/41df34c10780aa32afcc1bd59028ecb4a58af713/ead3.xsd#L1402)

The problem only manifests in this version of the schema, so it is a simple enough manual change even if it needs to be repeated. Remember that the XSDs must be manually edited after the deglobalize XSL is run anyway, so the instruction about e.anyname wouldn't be adding a manual step.

I'll go ahead and make the manual edit to the issue_#499 branch and test against libxml just to make sure. If it works, I think this is the way to go.

[rockivist]

@tcatapano This seems like the practical way forward.

[tcatapano]

Implemented manual fix to ead3_undprecated.xsd. Tested against sample S.0001.valid.xml using both xerces and LIBXML. Would be ideal to have a sample instance with deprecated elements which uses objectxmlwrap...

[fordmadox]

I'm re-opening this issue. Now that I'm prepping version 1.1.1, I realize that we haven't yet fixed this issue in the publication pipeline. It would be good to do that before 1.2 rolls around.

[fordmadox]

I also think we might want to change that namespace attribute, otherwise I think there's a difference between what's supported in the RNG vs XSD. So, I think this could/should be:

  <xs:complexType name="e.anyname">
      <xs:sequence>
         <xs:any namespace="##other" processContents="lax"/>
      </xs:sequence>
  </xs:complexType>

But I need to test that out to make sure I'm reading this correctly :)

[tcatapano]

@fordmadox Very good chance I may be misunderstanding, but do you really want to use "##other"? Wont that prevent wrapping of content within the ead3 namespace.

[fordmadox]

@tcatapano : my understanding was that the 1.1.0 XSD would validate anything at all within the objectxmlwrap element, whereas the RNG was set up to only allow namespaces other than the EAD3 namespace.

I just tested a few different variations (both with Xerces and Xmllint), and I think that the results that i'm getting now agree with the tag library. if you have a chance, please check out https://github.com/SAA-SDT/EAD3/releases/tag/v.1.1.1. And for ease of testing, I've added this EAD3 variant, which should prove invalid due to the second instance of the objectxmlwrap element: https://github.com/SAA-SDT/EAD3/blob/v1.1.1-develop/samples/ead3/EAD3test-xsd.xml

[fordmadox]

Noting this here as well as the subteam notes directory in Github until we can set up an automated testing procedure. Here's a reminder to test out this issue with xmllint, which can be run from the root of a new release branch (e.g. v1.1.1-develop), like so:

xmllint --noout --schema ead3.xsd samples/ead3/EAD3test-xsd.xml

[fordmadox]

Keeping this open since the change required (for now) is still a manual one. Should assign to 1.2, once that comes around.

[kerstarno]

Moved this to 1.2 (even though we are not yet certain that and when we'll have such a release) in order to have the milestone for release 1.1.1 cleared.