>From: Carlos Ugarte
>Sent: Tue, August 10, 2010 8:23:01 AM
>
> Dave,
>
> In your documentation you recommend comparing the output of
> running the main from the generated python code against the
> original xml.
> Did you try that with these files?
> There is a significant difference.
Carlos -
You are right that comparing the output with the original XML is a
good idea. I looked at that this morning, and you are also right
that there are significant differences.
I believe that part of the problem is that generateDS.py is being
fooled by some of those abstract="true" declarations. That's still
something that I do not understand very well. I've read several
pieces about it on the Web in the last few days, and, while they do
not exactly contradict each other, taken together, the picture of
elements that are declared abstract and their use is complicated
enough so that I doubt that I can get get generateDS.py to handle
it all correctly.
That being said, it looks to me that, when we look at the generated
output from sending gsts_xtce_metadata_example.xml through code
generated from xtce_space_systemsV1_1.xsd, all the content is
there, with these differences:
1. Formatting -- The export methods add ignorable whitespace so
that the output is indented.
2. Type information -- The export methods add type information
(attribute 'type="..."') to some elements. I believe that this
is related to the abstract declarations in the schema, but am not
too sure.
3. In the exported XML, there are 4 extra occurrences of element
xtce:ParameterInstanceRef. This is because generateDS.py is not
handling a <choice> in the schema correctly. I'll need to look
into that.
4. The exported XML is missing the XML namespace prefix definition.
You can fix this by generating your Python code with the
--namespacedef command line option.
$ generateDS.py
--namespacedef='xmlns:xtce="http://www.omg.org/space/xtce";' ...
>
> I now see what you were eluding to in regard to abstract declarations.
>
Right. It appears to me that the authors of the schema were thinking of
what "abstract" means in terms of a class in object-oriented programming
languages. In most OOP languages, an abstract class is one that can have no
instances.
It's meaning in XML schema is related, but means something more, too.
I'm still learning about this.
> This might explain why the output is quite a bit different from the original.
> I am not sure if the problem is in the original xml file or not.
> There may be other issues with the generated code as well.
>
Yes. See above.
> Did you find any other issues with your investigation?
> Have you made any other changes to it?
>
Have you considered using another tool, or at least using another
Python XML package for some of your tasks. For my own work,
especially when I do not have a schema, I use lxml or ElementTree.
ElementTree is in the Python standard library; lxml is not and
requires a separate install. lxml implements the same API as
ElementTree but has a few features that ElementTree does not have.
You might also want to take a look at objectify, which is part of
the lxml package. It attempts to give you a more Pythonic style of
access to elements. I think of it as getting you part way toward
what generateDS.py is trying to give you. See:
http://codespeak.net/lxml/objectify.html
http://codespeak.net/lxml/FAQ.html#what-is-the-difference-between-lxml-etree-and-lxml-objectify
I suppose that my recommendation (and you need to evaluate this for
yourself, of course) is that, if you can make some use of the code
generated by generateDS.py and can save some development time by
doing so, then good. But, given the problems that we've found with
handling your schema, you should *not* rely on it as your only tool.
Hope this helps. I'll report back if and when I've been able to fix
any of these problems.
- Dave
--
Dave Kuhlman
http://www.rexx.com/~dkuhlman
------------------------------------------------------------------------------
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________
generateds-users mailing list
generateds-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/generateds-users
