-
Notifications
You must be signed in to change notification settings - Fork 7
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
xml version #2
Comments
Can you help me on that one? Does it impact the parser? We only read strings and do all dates parsing ourselves in the code, maybe it doesn't matter then... |
Sure. Unless you use a legacy parser all current parsers should support xml1.1. Which one do you use? For the colours i used this: because I noticed that you defined everything as string. <choice>
<data type="hexBinary">
<param name="length">3</param>
</data>
<data type="string">
<param name="pattern">#[0-9a-fA-F]{6}</param>
</data>
</choice> I don't understand why you stick to strings though? From my understanding using more specific datatypes in the schema should be more efficient for parsing large files, and also help to generate more meaningful validation errors? |
We're using Java's "javax.xml.stream" XMLStreamReader which is the state of the art. I think we can more strict on the datatypes it won't break our parser but I'm really not sure. For the rest, it's all legacy I frankly have no idea how this schemas came to life, @sheymann may know more as he created them. |
I see I used Xerces and Saxon to test my changes to the schema. So far all is good, but i haven't really checked for xml1.1 specific features. In the end going from one to the other is a simple search + replace operation. Since some users wanted it, I ll try to make it work, if it doesn't, we'll just stick to xml1.0. It turns out there are more xml1.0 strongholds then I anticipated. Especially for timezone support having the proper datatypes would make my live a bit easier. |
No, we specifically disabled validation. I'm not sure exactly why but probably thought we should always try to read the gexf even with errors. |
gexf 1.3 could change to xml 1.1. I think it should be the default, but we'll have to make sure that this doesn't interfere with xml1.0 dates e.g. when importing gexf1.2 graphs.
The text was updated successfully, but these errors were encountered: