From boris at codesynthesis.com Wed Jun 11 06:24:14 2008 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Jul 1 03:37:21 2008 Subject: [xsde-users] XSD/e 2.1.0 released Message-ID: <20080611102414.GC5203@karelia> Hi, We have released XSD/e 2.1.0. The NEWS file entries for this release are as follows: * New delegation-based parser/serializer implementation reuse style in addition to virtual inheritance-based. The new style results in a much smaller object code size. The new reuse style is used by default and is incompatible with the old style. Applications that require backwards compatibility should use the --reuse-style-mixin option. The reuse support code now can be completely omitted with the --reuse-style-none option. A number of examples were converted to support both the new and old reuse styles while others were converted to support the new style only. For more information on the new reuse style see Section 5.6 in the Embedded C++/Parser Getting Started Guide and Section 6.6 in the Embedded C++/Serializer Getting Started Guide. * New option, --file-per-type, triggers generation of a separate set of C++ files for each type defined in XML Schema. This compilation mode is primarily useful when some of your schemas cannot be compiled separately or have cyclic dependencies which involve inheritance. Other new options that are useful in this compilation mode are --type-file-regex, --type-file-regex-trace, and --file-list. See the compiler command line manual (man pages) for more information. * New option, --options-file, allows additional command line options to be provided in files, with one option per line. * New option, --reserved-name, allows inserting additional names with optional replacements to the list of names that should not be used as identifiers. See the compiler command line manual (man pages) for details. * New options, --location-map, --location-regex, and --location-regex-trace, allow re-mapping of schema locations specified in the include and import elements without modifying the schema files. See the compiler command line manual (man pages) for more information. * New option, --guard-prefix, allows specifying a prefix that will be added to generated header inclusion guards. * New option, --file-list, triggers creation of a file with a list of generated C++ files. This option is primarily useful in the file-per- type compilation mode (--file-per-type) to create a list of generated C++ files, for example, as a makefile fragment. Other new options that are useful with --file-list are --file-list-prologue, --file-list-epilogue, and --file-list-delim. See the compiler command line manual (man pages) for more information. * In type map files the optional argument type now defaults to the return type if the return type ends with * or & (that is, it is a pointer or a reference) and 'const return type&' otherwise. * Type map files can now include comments. A comment starts with # and ends with a new line or end of file. To specify a name that contains # enclose it in "". C++/Parser * New option, --generate-polymorphic, triggers generation of polymorphism- aware code. This option should be used on XML vocabularies which use xsi:type and/or substitution groups. For more information see Section 5.7, "Support for Polymorphism" in the Embedded C++/Parser Mapping Getting Started Guide we well as the polymorphism and polyroot examples in the examples/cxx/parser/ directory. * New options, --generate-xml-schema and --extern-xml-schema, trigger generation of the mapping for the XML Schema namespace to a separate header file and inclusion of that header into other generated header files instead of generating the necessary declarations inline, respectively. See the the compiler command line manual (man pages) for details. * Support for parser reuse after an error. For more information refer to Section 7.4, "Reusing Parsers after an Error" in the Embedded C++/Parser Mapping Getting Started Guide. To suppress generation of the reset code use the --suppress-reset option. * New, context-based internal parsing architecture which provides better performance, especially for deeply-nested documents. This change should not affect user code except for wildcard parsing. See the wildcard example for the required changes. * The generated sample test driver file name was changed from -driver.cxx to -pdriver.cxx. C++/Serializer * The mapping now supports automatic generation of sample serializer implementations and a test driver. The --generate-empty-impl option triggers generation of a sample implementation with empty function bodies which can then be filled with application code. The --generate-test-driver option trigger generation of a test driver. For more information on this feature see the compiler command line manual (man pages). Other relevant new options include: --impl-file-suffix, --force-overwrite, --root-element-first, --root-element-last, and --root-element. * New option, --generate-polymorphic, triggers generation of polymorphism- aware code. This option should be used on XML vocabularies which use xsi:type and/or substitution groups. For more information see Section 6.7, "Support for Polymorphism" in the Embedded C++/Serializer Mapping Getting Started Guide we well as the polymorphism and polyroot examples in the examples/cxx/serializer/ directory. * New options, --generate-xml-schema and --extern-xml-schema, trigger generation of the mapping for the XML Schema namespace to a separate header file and inclusion of that header into other generated header files instead of generating the necessary declarations inline, respectively. See the the compiler command line manual (man pages) for details. * Support for serializer reuse after an error. For more information refer to Section 8.4, "Reusing Serializers after an Error" in the Embedded C++/Serializer Mapping Getting Started Guide. To suppress generation of the reset code use the --suppress-reset option. Precompiled binary distributions are available from the product's download page: http://www.codesynthesis.com/products/xsde/download.xhtml Source code for this release is available from the project's web page: http://www.codesynthesis.com/projects/xsde/ SHA1 checksums for the files: b8686f1bd8b8c9a7e73a54c61617784f169b351b xsde-2.1.0.tar.bz2 589272a7cfe11d9baa07fc2dc70b5005a643f2c8 xsde-2.1.0-i686-linux-gnu.tar.bz2 db464dc846e825c23d706a2bcb8e378cff577802 xsde-2.1.0-sparc-solaris.tar.gz 9cb43fd136d83a926aa1da7d01f0127fe67308e0 xsde-2.1.0-i686-windows.zip Enjoy, Boris From boris at codesynthesis.com Wed Jun 18 03:03:13 2008 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Jul 1 03:37:21 2008 Subject: [xsde-users] handling content of anyType Message-ID: <20080618070313.GA18877@karelia> Hi Ninh, In the future please send technical questions like these to the xsde-users mailing list (which I've CC'ed) instead of to me directly. This way other developers who may have experienced a similar problem can provide you with a solution. Plus questions and answers will be archived and available to others with similar problems. Ninh Tran Dang writes: > I have trouble when using XSDe to parse an empty element. The root parser > class doesn't allow me to set the parser for the person element. > > Because the element type under the root node is anyType, so it will accept > all xml elements under the root provided they are validated themselves, but > in this case I cannot parse the xml document. More precisely, anyType accepts any well-formed XML fragment. There won't be any XML Schema validation though. For example, in the sample XML you provided below, the person element won't be validated against the person element defined in the schema. > Could you answer me whether XSDe supports to parse this kind of schema? Or > do we have anyway to overcome this situation? Similar to wildcards (any and anyAttribute) all content matched by anyType will be reported via the following "raw XML" callbacks: virtual void _start_any_element (const xml_schema::ro_string& ns, const xml_schema::ro_string& name); virtual void _end_any_element (const xml_schema::ro_string& ns, const xml_schema::ro_string& name); virtual void _any_attribute (const xml_schema::ro_string& ns, const xml_schema::ro_string& name, const xml_schema::ro_string& value); virtual void _any_characters (const xml_schema::ro_string&); You can override them in root_pimpl. If you know that the content matched by anyType can be parsed by some other parser (e.g., person_pimpl in the below example), then you can route these calls to the corresponding parser. For more information on how to do this refer to the wildcard example in examples/cxx/parser/wildcard/. Boris [The rest of the original email follows for context.] > > Thanks, > > Ninh > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> > > > String > String > > > > > > > elementFormDefault="qualified" > attributeFormDefault="unqualified"> > > > > > > > > > > > > > > > > > > > > From ntlkhuong at tma.com.vn Wed Jun 25 05:50:44 2008 From: ntlkhuong at tma.com.vn (Khuong Nguyen Thi Lien) Date: Tue Jul 1 03:37:21 2008 Subject: [xsde-users] Cannot get the value Message-ID: <002f01c8d6a8$f0467be0$43b010ac@tma.com.vn> Hi, Currently, I am using the xsde 2.1.0. But I have a problem when parsing the schema: I have some confusion the about type of startup and substitutionGroup of startup. I found that the skeleton parser created 3 three map entries for them. But I don't know how I access those values. Could you help that? Thanks and best regards, Khuong From boris at codesynthesis.com Wed Jun 25 09:25:20 2008 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Jul 1 03:37:21 2008 Subject: [xsde-users] Cannot get the value In-Reply-To: <002f01c8d6a8$f0467be0$43b010ac@tma.com.vn> References: <002f01c8d6a8$f0467be0$43b010ac@tma.com.vn> Message-ID: <20080625132520.GK12421@karelia> Hi Khuong, Khuong Nguyen Thi Lien writes: > > > abstract="true"/> > > substitutionGroup="config-name"/> > > substitutionGroup="config-name"/> > > substitutionGroup="config-name"/> > This schema does not make much sense since the elements that substitute config-name (startup, candidate, and running) all use the same type as config-name. Normally you would have types derived from configNameType for startup, candidate, and running, for example (normally such types would also include additional elements/attributes): Then you would implement parser skeletons for each of them and add them to the map that is used to parse config-name. During parsing, depending on the actual element name found in XML (e.g., running, startup, etc.), the corresponding parser skeleton will be executed. Boris