I think that, as long as this symbol is not decoded from its HTML representation, it should be acceptable.
So my impression is that this is an ObsPy bug.
What do you think?
Let me know if you want me to open an issue on GitHub.
XML has five special chars that have to be encoded, and > is among them:
Thus lxml correctly decodes it to its string representation. What is actually in the XML are the decoded > which are not valid according to the QuakeML specification. The spec/schema are of course evaluated for the decoded XML. Concluding I think ObsPy is correct in complaining here as it indeed is not a valid resource identifier. jing thinks the same and complains about the example file when validating against the quakeml relaxng schema: /Users/lion/Desktop/ipgp2016afqtcu.xml:61:127: error: value of attribute “publicID” is invalid; must be a URI � (repeated a couple of times)
Ignore what I said about jing - it does complain but about some other resource identifiers. I still think my reasoning is sound but let me know if you disagree. Also it might be a good idea to move the discussion to github as it might become very technical.
is there a changelog or a discussion somewhere regarding what changed in
seiscomp? We are currently discussing if this is valid QuakeML or not
and would be great to get some more input.