Hi, I am facing some issues while processing a particular very (*very*) large schema, namely Juniper JunOS DMI configuration schema:
http://www.juniper.net/documentation/en_US/junos-space14.1/platform/topics/concept/junos-space-getting-started-dmi-schema-overview.html 1. The schema contains elements named "self". Among other things, this leads to constructor signatures repeating self as a keyword argument, for example: def __init__(self, undocumented=None, comment=None, self=None, peer_address=None, address=None, reject=None, discard=None, next_table=None): This is an error, but I think it can be overcome by adding it to NameTable: NameTable = { 'self': 'iself', } If that is the case, perhaps it would make sense to include it in the default NameTable? 2. Dashes in some element names (like "ieee-802-3ad") are not always properly substituted, for example: self.validate_ieee-802-3adType(self.ieee_802_3ad) Apparently this is fixed with the following change: --- a/generateDS.py 2016-04-27 01:36:09.000000000 +0300 +++ b/generateDS.py 2016-05-28 09:47:13.582542930 +0300 @@ -4207,7 +4207,7 @@ # a warning so no fear that an error would rise. if (child.getSimpleType()): wrt(' self.validate_%s(self.%s)\n' % ( - child.getSimpleType(), name)) + cleanupName(child.getSimpleType()), name)) eltype = element.getType() if (element.getSimpleContent() or element.isMixed() or 3. This complex and very large schema contains elements by the same name nested at various levels. For example there seem to be numerous elements named "configuration" (using xpath to show context): xsd:schema/xsd:element[@name='configuration'] xsd:schema/xsd:element/xsd:complexType/xsd:sequence/xsd:choice/xsd:element/xsd:complexType/xsd:sequence/xsd:choice/xsd:element/xsd:complexType/xsd:sequence/xsd:choice/xsd:element/xsd:complexType/xsd:sequence/xsd:choice/xsd:element/xsd:complexType/xsd:sequence/xsd:choice/xsd:element/xsd:complexType/xsd:sequence/xsd:choice/xsd:element[@name='configuration' and @minOccurs='0'] xsd:schema/xsd:element/xsd:complexType/xsd:sequence/xsd:choice/xsd:element/xsd:complexType/xsd:sequence/xsd:choice/xsd:element/xsd:complexType/xsd:sequence/xsd:choice/xsd:element/xsd:complexType/xsd:sequence/xsd:choice/xsd:element[@name='configuration' and @minOccurs='0'] xsd:schema/xsd:complexType/xsd:sequence/xsd:choice/xsd:element/xsd:complexType/xsd:sequence/xsd:choice/xsd:element/xsd:complexType/xsd:sequence/xsd:choice/xsd:element/xsd:complexType/xsd:sequence/xsd:choice/xsd:element[@name='configuration' and @minOccurs='0'] xsd:schema/xsd:complexType/xsd:sequence/xsd:choice/xsd:element/xsd:complexType/xsd:sequence/xsd:choice/xsd:element[@name='configuration' and @minOccurs='0'] xsd:schema/xsd:complexType/xsd:sequence/xsd:choice/xsd:element/xsd:complexType/xsd:sequence/xsd:choice/xsd:element[@name='configuration' and @minOccurs='0'] I'm not sure if that is a problem per se, schema-wise. generateDS creates classes for each of these, suffixed with some number: class configuration(GeneratedsSuper): class configurationType1642(GeneratedsSuper): class configurationType19343(GeneratedsSuper): class configuration_databaseType(GeneratedsSuper): class configuration_breadcrumbsType(GeneratedsSuper): So far, so good, I guesss. However, problems arise when the GDSClassesMapping dictionary comes into play. This maps "configuration" to just one of those classes, perhaps the last one generateDS encountered in the schema. So in the particular case, it show such a mapping: 'configuration': configurationType19343 This is not the root "configuration" element. Parsing an instance XML document produces a single "empty" configuration node. The particular issue is easy to fix, I simply changed the mapping to the configuration class. However I wonder what are the overall implications of this pattern: Due to mapping of elements etc. via the GDSClassesMapping dictionary, some of these "duplicate" elements are inevitably "lost". Should gDS be able to handle such a pattern and, if so, how? (4.) This schema also contains a number (276) of xs:any declarations. I understand this is a known limitation, but it is a considerable pain: affected elements are lost when parsing an instance document and exporting it again. 5. This is an uncomfortably large schema. The schema itself (config.xsd, I am using version 15.1R2) is 106 MB! Processing it with generateDS --export="write literal etree" produces a 222 MB module. Importing such a module in python 2.7.9 takes 9 seconds and uses a whooping 766 MB of memory. Regardless of any other issues, the module is barely usable due to the above. Of course the schema is the problem in the first place. Juniper probably could split it to smaller schema documents, but I wonder if there could be some way to split the produced module in smaller sub-modules, perhaps following the schema hierarchy. Even if this is (probably) not supported by gDS, I would like to know Dave's opinion about this idea, and any suggested approach for doing this manually. Thanks, Zenon ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e _______________________________________________ generateds-users mailing list generateds-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/generateds-users
