Hi Stefan,
Is it easily possible to use QNames in the xsi-type lookup system?
I believe this would be the right thing to do, as lxml should be consistent. If XMLSchema handles it one way, objectify should handle it the same way.
However, it is actually harder than you might think. In ET, namespaces use the Clark notation, but the standard requires prefixes here. Assuming that people always use "xsd" as prefix is error prone, so we'd have to look up the right prefix for each element when we store it and make sure the namespace is declared. We should definitely use the xsd prefix if we declare it internally, to make it less likely that users deploy the same prefix for a different namespace.
More importantly, when we look up the type, we'd have to check for the namespace referenced by the prefix to make sure it's an XMLSchema type.
Alternatively, we could switch to writing out the prefixed version internally and just ignore the prefix when figuring out the type. That would prevent people from using data types from other namespaces, but that's an unlikely use case anyway. If you want to do that, you can stick to registering a Python type.
I could certainly live with that for my application :-).
I wouldn't mind changing it to the prefixed version - as usual: better now than later. Changing this means that the typed XML that newer versions of objectify write out will not be read as expected by version 1.2. Sounds acceptable to me.
Again, this would work for me. I guess the objectified.Element() factory should then have the schema namespace added to its _DEFAULT_NSMAP, right?
I would like to hear other opinions on this before the release of 1.3, which will define the way this will be handled in the future.
When parsing a document that declares the schema namespace, will the prefixed write-out be able to pick up this prefix, or will it always use "xsd"? Holger -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail