Hi Dave,

Thank you for your patch. I have tested for vcloud xsd files. I believe it 
resolves the 2 issues. But just got a new issue, well... actually I found it 
last week but forgot to report... I replaced all xsd localtions to local path 
in xsd's, but still failed to generate pys files for vcloud. The new issue may 
be caused by the circular references.


Below is the cmd I used:
c:\Python27\Scripts>python.exe generateDS.py -f --one-file-per-xsd 
--output-directory="c:\tmp" <my 
folder>\schema-files\1.5\schemas\extension\vmwextensions.xsd


But I only got 2 output .py files and "Task.py" is empty. And the cmd never 
exit...

I looked into these xsds and found the circular references as below:


Task.xsd:
<xs:include schemaLocation="entity.xsd"/>
    <xs:include schemaLocation="common.xsd"/>


Entity.xsd
<xs:include schemaLocation="common.xsd"/>
    <xs:include schemaLocation="task.xsd"/>
Common.xsd
<xs:include schemaLocation="task.xsd"/>



--


Best Regards

Jinquan




At 2014-03-05 08:10:46,"Dave Kuhlman" <dkuhl...@davekuhlman.org> wrote:
>> Thanks a lot for your quick response!
>> 
>> I forgot to tell you another issue I encountered yesterday. In
>> vcloud schema, there're some extension types for vcenter (like
>> \extension\vmwextensions.xsd). If I took this xsd as root xsd, I
>> found the type in master.xsd would be generated as well. But seems
>> the order of the output classes is not right. It reported
>> "ResourceType" is not defined.
>
>Jinquan,
>
>I believe that I have fixes (see attached) for 2 of the 3 problems
>you reported:
>
>1. Issues with one-file-per-xsd -- Error occurred when the
>   include/import element referenced a schema on the Net (rather
>   than the local file system).  Added support to read remote
>   content (in a way similar to what process_includes.py already
>   does).
>
>2. Order of output classes not right -- generateDS.py was not
>   correctly handling anonymous xs:simpleType, which caused it to
>   believe that it had previously generating a class when it
>   actually had not.
>
>I still do *not* have a fix for the following problem:
>
>3. Some elements in "1.xml" are not serialized. e.g.
>   <NetworkConfigSection>, <LeaseSettingsSection>, etc. -- I'll work
>   on this one some more tomorrow.  Several things might be involved,
>   including substitutionGroups and abstract super classes/types.  I
>   have to track down which is causing this error.
>
>A patch file is attached for issues 1 and 2, above.  If you get a
>chance to try it, please let me know whether these fixes work for
>you.
>
>I'll follow up with issue 3 above in a day or so, I hope.
>
>Thanks for your help with this.
>
>Dave
>
>-- 
>
>Dave Kuhlman
>http://www.davekuhlman.org
------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works. 
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
generateds-users mailing list
generateds-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/generateds-users

Reply via email to