Skip to content
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

xmllint complains about objectxmlwrap in xsd #499

Open
tcatapano opened this issue Aug 17, 2015 · 23 comments
Open

xmllint complains about objectxmlwrap in xsd #499

tcatapano opened this issue Aug 17, 2015 · 23 comments

Comments

@tcatapano
Copy link
Member

tcatapano commented Aug 17, 2015

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
Copy link
Member Author

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

@ottosmops
Copy link

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

@shsdev
Copy link

shsdev commented Jun 7, 2016

Same issue using python lxml.

@tcatapano
Copy link
Member Author

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

@shsdev
Copy link

shsdev commented Jun 7, 2016

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

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

@tcatapano
Copy link
Member Author

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

@tcatapano tcatapano added the Bugs label Nov 4, 2016
@tcatapano tcatapano added this to the 1.01 milestone Nov 4, 2016
@tcatapano tcatapano self-assigned this Nov 4, 2016
@rockivist
Copy link
Member

@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
Copy link
Member

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
Copy link
Member Author

Need to test using ruby/nokigiri and python/lxml

@tcatapano
Copy link
Member Author

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

@tcatapano tcatapano reopened this May 24, 2017
tcatapano pushed a commit that referenced this issue May 24, 2017
@tcatapano
Copy link
Member Author

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

@fordmadox
Copy link
Member

@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
Copy link
Member Author

@fordmadox I'll look into today and report back

@tcatapano
Copy link
Member Author

@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:

<xs:complexType name="e.anyname">
)

to

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

(as at:

EAD3/ead3.xsd

Line 1402 in 41df34c

<xs:complexType name="e.anyname">
)

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
Copy link
Member

@tcatapano This seems like the practical way forward.

tcatapano added a commit that referenced this issue Oct 19, 2017
@tcatapano
Copy link
Member Author

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
Copy link
Member

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 fordmadox reopened this Nov 21, 2019
@fordmadox
Copy link
Member

fordmadox commented Nov 21, 2019

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
Copy link
Member Author

@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
Copy link
Member

fordmadox commented Nov 21, 2019

@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
Copy link
Member

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

@kerstarno kerstarno modified the milestones: 1.0.1, 1.1.1 Dec 17, 2019
@fordmadox
Copy link
Member

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

@kerstarno kerstarno assigned fordmadox and kerstarno and unassigned tcatapano Dec 18, 2019
@kerstarno kerstarno modified the milestones: 1.1.1, 1.2.0 Apr 23, 2020
@kerstarno
Copy link
Contributor

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.

@kerstarno kerstarno modified the milestones: 1.2.0, Schematron update Dec 8, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants