From mark at digitalfountain.com Thu Feb 1 00:34:33 2007 From: mark at digitalfountain.com (Mark Watson) Date: Sun Oct 11 15:33:52 2009 Subject: [xsd-users] W3C SMIL Schema Message-ID: Hi, I have been trying to get xsd to compile the W3C SMIL schema at http://www.w3.org/TR/2005/REC-SMIL2-20050107/smil-SCHEMA.html. I am new to both xsd and SMIL. Aside from a few minor bugs, these Schemas seem to have the property that there are mutual cross-references between namespaces. Specifically, when compiling the root file (smil.xsd), there are first a number of included files which define symbols in the smil20 namespace. Some of these use symbols from the smil20lang namespace, in which nothing has yet been defined. There are no import statements for smil20lang in these included files, which cause xsd to generate errors and it?s not possible to add an import for smil20lang, because the definition of most things in this namespace relies on the smil20 stuff we are trying to define. Re-arranging the files so that all the initial smil20 stuff is done first, and following this with the import of the file which defines things in smil20lang works better, but I still get reports from xsd of unrecognised symbols in one included file which were clearly defined in an earlier included file. Furthermore, I believe there are further additions to smil20 which happen later but are referenced for the earlier smil20lang stuff. I am not an expert in XML, and one question I have is whether this kind of referencing ? which seems not to respect any kind of compilation order ? is valid in XML but just not supported by xsd, or whether it is not allowed in XML at all. Any help greatly appreciated. Best regards, Mark Watson From boris at codesynthesis.com Thu Feb 1 07:54:27 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:52 2009 Subject: [xsd-users] W3C SMIL Schema In-Reply-To: References: Message-ID: <20070201125427.GA11033@karelia> Hi Mark, Mark Watson writes: > Aside from a few minor bugs, these Schemas seem to have the property that > there are mutual cross-references between namespaces. Specifically, when > compiling the root file (smil.xsd), there are first a number of included > files which define symbols in the smil20 namespace. Some of these use > symbols from the smil20lang namespace, in which nothing has yet been > defined. There are no import statements for smil20lang in these included > files, which cause xsd to generate errors and it?s not possible to add an > import for smil20lang, because the definition of most things in this > namespace relies on the smil20 stuff we are trying to define. I've already met this same problem in GML (Geography Markup Language) schemas. They use stripped-down (and fixed up) version of SMIL 2.0 which was fairly trivial to fix to get rid of the circular dependency as described on this page: http://wiki.codesynthesis.com/Schemas/GML The full SMIL schemas requires quite a bit more splitting but I managed to get it compiled with XSD 3.2.1. Instructions and modified schema can be obtained from this page: http://wiki.codesynthesis.com/Schemas/SMIL > I am not an expert in XML, and one question I have is whether this kind of > referencing ? which seems not to respect any kind of compilation order ? is > valid in XML but just not supported by xsd, or whether it is not allowed in > XML at all. It is valid per XML Schema spec (though it is arguably poor design) but not yet supported by XSD. XSD uses so-called "one source files per schema file" compilation model where every schema file is compiled separately and XML Schema import/include statements are mapped to preprocessor #include directives. This results in a requirement that every schema file be valid by itself (i.e., has all the necessary schemas included or imported). This is not the case for SMIL. We are planning to introduce an option in the next version of XSD that will allow you to "collapse" all includes and imports into a single generated source file. This should work fairly well for schemas like SMIL. hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070201/665ec4dd/attachment.pgp From david.r.moss at selex-comm.com Fri Feb 2 05:37:13 2007 From: david.r.moss at selex-comm.com (Moss, David R (SELEX Comms) (UK Christchurch)) Date: Sun Oct 11 15:33:52 2009 Subject: [xsd-users] Support for redefine In-Reply-To: <20070201125427.GA11033@karelia> Message-ID: Boris, Are there any plans to support redefine? Compilation with 2.3.1 outputs: "error: unexpected top-level element: 'redefine'" I'm looking for a way to extend a type in such a way that the element name will remain the same, since my code expects an operation to exist with that name; Services() in the case of the attached files. Given those files, I'd want to be able to create a derived user type that can use the extended Services_t. In the generated code, I guess the issue would be 'hiding' the first class definition when a redefinition is encountered; the standard states that the extension would apply to all schema components that make use of Services_t. I may be able to do something else using the generated type customisation approach to insert a function into a services object hierarchy (in conjunction with substitution groups) which my code would then use but I think this may cause other issues (I need to investigate this further!). Any thoughts greatly appreciated. Cheers, Dave. Dave Moss SELEX Communications Grange Road Christchurch Dorset BH23 4JE United Kingdom Tel: + 44 (0) 1202 404841 Email: david.r.moss@selex-comm.com ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** -------------- next part -------------- A non-text attachment was scrubbed... Name: _test-user-config.xsd Type: application/octet-stream Size: 597 bytes Desc: _test-user-config.xsd Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070202/b177ee33/_test-user-config.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: _redefine-test-user-config.xsd Type: application/octet-stream Size: 572 bytes Desc: _redefine-test-user-config.xsd Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070202/b177ee33/_redefine-test-user-config.obj From boris at codesynthesis.com Fri Feb 2 06:15:52 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:52 2009 Subject: [xsd-users] Re: Support for redefine In-Reply-To: References: <20070201125427.GA11033@karelia> Message-ID: <20070202111552.GA13537@karelia> Hi David, Moss, David R (SELEX Comms) (UK Christchurch) writes: > Are there any plans to support redefine? No there are no plans to support redefine, mainly for the following three reasons: 1. It is not widely used 2. Many believe it is a mis-feature 3. It is not clear what the C++ mapping would be > I'm looking for a way to extend a type in such a way that the element > name will remain the same, since my code expects an operation to exist > with that name; Services() in the case of the attached files. You can do this with xsi:type, though it is not exactly equivalent to using redefine. Another, somewhat less elegant but simpler, alternative would be to add the CallBack element as optional to the original Service_t. This is conceptually equivalent to redefine since the original schema will need to "see" the redefine in order to be able to use it (i.e., there is no "dynamic redefine", as there is with polymorphism). I think the main idea of redefine is to be able change the schema that you cannot physically change. > In the generated code, I guess the issue would be 'hiding' the first > class definition when a redefinition is encountered; the standard states > that the extension would apply to all schema components that make use of > Services_t. It cannot be just hidden since only the schemas (and generated code) that "saw" the redefined type will be able to use it. > I may be able to do something else using the generated type > customisation approach to insert a function into a services object > hierarchy (in conjunction with substitution groups) which my code would > then use but I think this may cause other issues (I need to investigate > this further!). Even when using substitution groups, you get the same Service() function in TestUserConfig. The only "visible" difference between using substitution groups, xsi:type, and redefine/optional element is what the XML instance is going to look like and how you access the data. Here is the summary: 1. Substitution groups: instance have different element names for base and derived types. Access is polymorphic (can use dynamic_cast to distinguish between base and derived). 2. xsi:type: instance have the same element name for base and derived but will need xsi:type attribute for derive. Access is polymorphic (can use dynamic_cast to distinguish between base and derived). 3. Optional element: instance have the same element name. To get to the "extension" (CallBack) you simply need to check for presence. hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070202/4849be60/attachment.pgp From felix.zielke at iais.fraunhofer.de Fri Feb 2 09:12:26 2007 From: felix.zielke at iais.fraunhofer.de (Felix Zielke) Date: Sun Oct 11 15:33:52 2009 Subject: [xsd-users] Mpeg-7 schema support? Problem: Message-ID: <31628185.2871170425546377.OPEN-XCHANGE.WebMail.tomcat@ox.iais.fraunhofer.de> Hi Mattis, I have the same problem with the mpeg-7 schema. It is astonishing that there are very few google hits on that issue. Stylus XML Studio detects that UPA rule violation. I would very much like to know what the mpeg-7 guys say to that. Did you contact anyone? If you will, please let me know. Cheers, Felix From david.r.moss at selex-comm.com Fri Feb 2 10:09:07 2007 From: david.r.moss at selex-comm.com (Moss, David R (SELEX Comms) (UK Christchurch)) Date: Sun Oct 11 15:33:52 2009 Subject: [xsd-users] RE: Support for redefine In-Reply-To: <20070202111552.GA13537@karelia> Message-ID: Boris, > 2. xsi:type: instance have the same element name for base and derived > but will need xsi:type attribute for derive. Access is polymorphic > (can use dynamic_cast to distinguish between base and derived). This looks like the best approach but with the code below and the attached files I'm getting the error: error: Unresolved type 'd:DServices_t' found in xsi:type handling #include #include #include "derived-user-config.hxx" using namespace std; main() { try { using namespace Base; auto_ptr db( UserDatabase( "test-users.xml" ) ); } catch( xml_schema::exception const& e) { cerr << e << endl; } } This feels like another 'I'm missing something obvious' moment...! Cheers, Dave. Dave Moss SELEX Communications Grange Road Christchurch Dorset BH23 4JE United Kingdom Tel: + 44 (0) 1202 404841 Email: david.r.moss@selex-comm.com ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** -------------- next part -------------- A non-text attachment was scrubbed... Name: derived-user-config.xsd Type: application/octet-stream Size: 922 bytes Desc: derived-user-config.xsd Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070202/52364d78/derived-user-config.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: test-user-config.xsd Type: application/octet-stream Size: 651 bytes Desc: test-user-config.xsd Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070202/52364d78/test-user-config.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: test-users.xsd Type: application/octet-stream Size: 683 bytes Desc: test-users.xsd Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070202/52364d78/test-users.obj From boris at codesynthesis.com Fri Feb 2 10:11:11 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:52 2009 Subject: [xsd-users] Re: Support for redefine In-Reply-To: References: <20070202111552.GA13537@karelia> Message-ID: <20070202151111.GB13537@karelia> Hi David, Moss, David R (SELEX Comms) (UK Christchurch) writes: > error: Unresolved type 'd:DServices_t' found in xsi:type handling I assume you are running into this problem when running the test program on test-users.xml. If so then could you provide that file as well? Without seeing the file, my bet would be that you forgot to add derived-user-config.xsd to the schemaLocation attribute. hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070202/7202e90d/attachment.pgp From boris at codesynthesis.com Mon Feb 5 02:15:31 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:52 2009 Subject: [xsd-users] Mpeg-7 schema support? Problem: In-Reply-To: <31628185.2871170425546377.OPEN-XCHANGE.WebMail.tomcat@ox.iais.fraunhofer.de> References: <31628185.2871170425546377.OPEN-XCHANGE.WebMail.tomcat@ox.iais.fraunhofer.de> Message-ID: <20070205071531.GB8013@karelia> Hi Felix, Felix Zielke writes: > I have the same problem with the mpeg-7 schema. It is astonishing that > there are very few google hits on that issue. Stylus XML Studio detects > that UPA rule violation. I would very much like to know what the mpeg-7 > guys say to that. Did you contact anyone? If you will, please let me > know. Here is the information Mattis sent me privately. He apparently contacted mpeg7 working group and they seem to agree they've got a bug. hth, -boris ----- Forwarded message from Mattis Fjallstrom ----- Hi Boris, Just to let you know, you were right. :-) I got some more information on the mpeg-7 schema problem. Cheers, Mattis ---------------------------- Original Message ---------------------------- Subject: Re: FW: Mpeg7 schema, potential bug From: "Gerrard Drury" Date: Wed, November 15, 2006 12:02 am To: "Mattis Fjallstrom" Cc: i.burnett@elec.uow.edu.au -------------------------------------------------------------------------- Hello Mattis, My name is Gerrard Drury and I work with Associate Professor Ian S Burnett at the University of Wollongong. Ian is the current chair of the MDS subgroup of MPEG. I was not actually involved in the development of MPEG-7 MDS (my involvement with MPEG is in the area of MPEG-21), however I have had a look at the schema errors you have identified. Indeed the errors identified by Boris are a problem with the mds-2001.xsd schema. Note that I am using Oxygen XML 7.2 and this picked up the errors ok. (It picked up a similar error in a few other places also.) I suspect that back when MPEG-7 was being finalised, in about 2001, the tools used to validate the schema did not pick up the problems. The semantics for ShotEditingTemporalDecompositionType as stated in ISO/IEC 15938-5 (subclause 11.9.8) state: > In an ShotEditingTemporalDecomposition DS > description, the CompositionShot DS and > CompositionTransition DS descriptions shall be > ordered in time. Furthermore, a CompositionShot DS > description can be preceded and followed by a > CompositionTransition DS description, but not by > another CompositionShot DS description Hence I think that the schema is intended to express this, but unfortunately as currently expressed it does violate the UPA rule. The consequence for the MPEG-7 MDS schema is that we would require issuing a corrigendum to correct the schema such that it is valid as per W3C XML Schema. However to do this we would also need to somehow come up with alternative XML Schema definitions that express the intended XML syntax and is also valid W3C XML Schema. To initiate action for a corrigenda to be undertaken would require submitting a Defect Report for ISO/IEC 15938-5. Such a Defect Report would contain information such as - references to locations in the document(s) where the defect occurs, - nature of the defect (in this case an "error"), - explanation of the problem, and - optionally, a proposal to correct the problem Ian might correct me on the procedure, but I think that normally such a Defect Report would be a SC 29/WG 11 document output from an MPEG meeting. In this case it would probably be prompted by an input contribution to an MPEG meeting that basically provided all the required information that would go in to the official Defect Report. In regards to a possible solution, if you want to widen the discussion you could possibly try posting to the following list: http://lists.mpegif.org/mailman/listinfo/mp7-tech However note that there has been no activity on this list for over a year. Alternatively, as this is also a more general question of how to express a desired XML syntax in W3C XML Schema, another option might be to searching/posting to the XML schema list. http://lists.w3.org/Archives/Public/xmlschema-dev/ One thread I saw recently that might be helpful, though they are solving a somewhat different problem: http://lists.w3.org/Archives/Public/xmlschema-dev/2006Oct/0013.html To simplify the discussion a bit, maybe if we define S = choice of CompositionShot or CompositionShotRef T = choice of CompositionTransition or CompositionTransitionRef I think that, in my interpretation of the text and the schema as it currently is, what is basically desired is that the syntax allows for alternating S and T elements with possibly only one of either S or T. i.e. element sequences like S ST STS STST STSTS STSTST ... T TS TST TSTS TSTST TSTSTS ... (It would actually be good to clarify this with some of the original people that worked on this technology. I will try to follow this up with some contacts we have.) I would have to give it some more thought as to how this might be able to be expressed n W3C XML Schema, however it might be that it cannot be done. Hope that some of this information has been of help. Kind Regards, Gerrard Ian Burnett wrote: > Gerrard, > > Any comments? > > Ian > > -----Original Message----- > From: Leonardo Chiariglione [mailto:leonardo@chiariglione.org] > Sent: Tuesday, November 14, 2006 7:27 PM > To: Ian S Burnett > Cc: mattis@acm.org > Subject: RE: Mpeg7 schema, potential bug > > Ian, > Can you help Mattis? > Leonardo > > Leonardo Chiariglione, Ph. D. > Digital Media Strategist > http://www.cedeo.net/ > > > > -----Original Message----- > From: Mattis Fjallstrom [mailto:mattis@sonic.net] > Sent: Tuesday, 14 November, 2006 03:31 > To: leonardo@chiariglione.org > Subject: Mpeg7 schema, potential bug > > Dear Professor Chiariglione, > > I hope this in not an inappropriate address to use. I found your name and > address on the Mpeg7 home pages, and I believe I have stumbled on a problem > (potential bug) in the Mpeg7 schema. I'm not sure who to direct my question > to - I tried one of the names on the FAQ, but the FAQ was written in 2000 > and the address on longer valid. If you are not the right person, maybe you > can point me in the right direction? > > My name is Mattis Fjallstrom, I'm currently doing video processing research > at KDDI in Japan. I'm trying to parse a set of Mpeg7 files that holds > information about our video clips. Previously, I used the Xerces parser as a > SAX parser and that works, but SAX is really an inappropriate choice for our > application. I found a data binding parser instead, but it won't accept the > Mpeg7 schema. Further analysis showed that this parser might be right. > > There is a part in the mds-2001.xsd document that seems like it would > violate the Unique Particle Attribution rule. Several of the popular parsers > doesn't realize this - but it means that an Mpeg7 document that conforms to > the schema may be unparseable. > > The information below comes from Boris Kolpackov (boris@codesynthesis.com) > who did most of the research on this one (seeing how I'm pretty new to > Mpeg7). > > Was this a known problem? Is there a way to fix it? > > Thank you and again, apologies if this got to the wrong person. > > Cheers, > > Mattis > > Mattis Fjallstrom > mattis@acm.org > > --------------------------------------------------------------------- > >>From Boris Kolpackov: > > > I finally got around to checking the mpeg-7 schemas and it seems they indeed > violate the UPA rule. Consider this fragment from mds-2001.xsd, line 3999: > > > > > > > > > type="mpeg7:CompositionTransitionType"/> > > > > > > > > > type="mpeg7:CompositionTransitionType"/> > > > > > In particular the last sequence and choice. When parser sees a > CompositionTransition element it does not know (without looking ahead) which > branch it happens to belong (sequence of choice). > > It is interesting to note that quite a few XML Schema processors report that > this schema is valid. In particular I tried Xerces-J, Jing, and MSV from > this service: > > http://www.mel.nist.gov/msid/validation/ > > All three of them reported that the schema is valid. I was wondering how > they were going to handle an instance for such a schema so I created a small > test schema that reproduces the questionable structure found in the > mpeg-7 schemas: > > > xmlns:t="test" > targetNamespace="test"> > > > > > > > > > > > > > > > > > > > > > > > > > And a test XML instance document: > > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="test test.xsd"> > > a > > > > Again, the above three processors all reported that the schema is valid. > However, when I tried to validate the instance against the schema all of > them failed saying that the instance is not valid (all of them assumed the > first branch and expected to see CompositionShot or CompositionShotRef > elements). Strangely enough, after reporting that the instance is not valid, > Jing also reported that the schema violates the UPA rule: > > ~/test.xsd:4:58: error: cos-nonambig: "":CompositionTransition and > "":CompositionTransition (or elements from their substitution group) > violate "Unique Particle Attribution". > > > hth, > -boris ----- End forwarded message ----- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070205/c4a11ae7/attachment.pgp From david.r.moss at selex-comm.com Mon Feb 5 03:49:41 2007 From: david.r.moss at selex-comm.com (Moss, David R (SELEX Comms) (UK Christchurch)) Date: Sun Oct 11 15:33:52 2009 Subject: [xsd-users] RE: Support for redefine In-Reply-To: <20070202151111.GB13537@karelia> Message-ID: Boris, > I assume you are running into this problem when running the test > program on test-users.xml. If so then could you provide that file > as well? My mistake - here it is! > Without seeing the file, my bet would be that you forgot > to add derived-user-config.xsd to the schemaLocation attribute. No, that doesn't seem to be the problem. I'm wondering whether it has anything to do with referencing an xsi:type (the services) within another xsi:type (the user)? Cheers, Dave Dave Moss SELEX Communications Grange Road Christchurch Dorset BH23 4JE United Kingdom Tel: + 44 (0) 1202 404841 Email: david.r.moss@selex-comm.com ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** -------------- next part -------------- A non-text attachment was scrubbed... Name: test-users.xml Type: text/xml Size: 635 bytes Desc: test-users.xml Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070205/5bea37ea/test-users.bin From boris at codesynthesis.com Mon Feb 5 04:08:49 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:52 2009 Subject: [xsd-users] Re: Support for redefine In-Reply-To: References: <20070202151111.GB13537@karelia> Message-ID: <20070205090849.GC8013@karelia> Hi David, Moss, David R (SELEX Comms) (UK Christchurch) writes: > No, that doesn't seem to be the problem. Your xsi:type attribute value is "d:DServices_t" while the type name is "DService_t" (without "s" in "Services"). After fixing this everything seems to work fine. hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070205/2ccede0d/attachment.pgp From david.r.moss at selex-comm.com Mon Feb 5 06:54:33 2007 From: david.r.moss at selex-comm.com (Moss, David R (SELEX Comms) (UK Christchurch)) Date: Sun Oct 11 15:33:52 2009 Subject: [xsd-users] RE: Support for redefine In-Reply-To: <20070205090849.GC8013@karelia> Message-ID: Boris, I spent ages looking at that - sorry! It all works now... Cheers, Dave. Dave Moss SELEX Communications Grange Road Christchurch Dorset BH23 4JE United Kingdom Tel: + 44 (0) 1202 404841 Email: david.r.moss@selex-comm.com ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From mark at digitalfountain.com Thu Feb 8 15:07:26 2007 From: mark at digitalfountain.com (Mark Watson) Date: Sun Oct 11 15:33:52 2009 Subject: [xsd-users] Groups and AttributeGroups In-Reply-To: Message-ID: Is there a way to avoid duplication of code generated for groups and attributeGroups when they are included in multiple elements ? When an attribubuteGroup is used within two distinct elements, then separate code seems to be generated in each element for the individual attributes in the group. Is it possible to generate a class for the attribute group as a whole and include this as a contained class (or super-class, if the resulting multiple inheritance is not too much of a problem) within each element which has the group ? This would make handling the resulting objects easier, as a single piece of code could handle the common attributes across the various objects which use those attributes. Alternatively, is there a different Schema construction instead of attributeGroup which could achieve the same thing. I thought of defining a type with the attributes and deriving the other types from that, but as I have several attribute groups to play with and (unless I missed something) XML does not support multiple inheritance (perhaps wisely). Regards, Mark Watson From boris at codesynthesis.com Thu Feb 8 15:34:31 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:52 2009 Subject: [xsd-users] Groups and AttributeGroups In-Reply-To: References: Message-ID: <20070208203431.GA27302@karelia> Hi Mark, Mark Watson writes: > Is there a way to avoid duplication of code generated for groups and > attributeGroups when they are included in multiple elements ? > > When an attribubuteGroup is used within two distinct elements, then separate > code seems to be generated in each element for the individual attributes in > the group. Is it possible to generate a class for the attribute group as a > whole and include this as a contained class (or super-class, if the > resulting multiple inheritance is not too much of a problem) within each > element which has the group ? There is no such facility at the moment. Groups are really a syntactic sugar that allows you to "copy" the same content into several types while keeping things manageable. The content of a group a set of element or attributes and as such is mapped to a bunch of functions that do not really result in much object code (most of them are inline and one line long). There are also technical difficulties in factoring a group out as a base class since the type can also have a real base type which would require multiple virtual inheritance and non-trivial parsing delegation to handle properly. > This would make handling the resulting objects easier, as a single piece of > code could handle the common attributes across the various objects which use > those attributes. You can achieve this with a function template. Suppose you have the following group: You could then write the following function template: template void process_g (X& x) { cout << "foo: " << x.foo () << endl << "bar: " << x.bar () << endl; } And call it on any instance of a type that embeds group g. > Alternatively, is there a different Schema construction instead of > attributeGroup which could achieve the same thing. I thought of defining a > type with the attributes and deriving the other types from that, but as I > have several attribute groups to play with and (unless I missed something) > XML does not support multiple inheritance (perhaps wisely). The inheritance mechanism is your best bet. White XML Schema does not support multiple inheritance, you can always create a base that has two or more groups in it. The drawback of this approach is that you won't be able to have a single base for each group which you could handle generically. For example, if you have three groups, G1, G2, and G3, then you will need two base classes that contain, say, G1: B1={G1,G2} and B2={G1,G3}. As a result you will need write two functions to handle group G1: one that takes B1 and the other that takes B2. Overall, I think the function template approach is cleaner and less verbose. hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070208/5dcf2590/attachment.pgp From Johan.denBoer at NS.NL Tue Feb 13 01:29:36 2007 From: Johan.denBoer at NS.NL (Boer den, Johan J (NSC)) Date: Sun Oct 11 15:33:52 2009 Subject: [xsd-users] XSD path location Message-ID: Hi, We have this problem : In our xml message there is a xsd filename specified. Our server who parse this xml message must have the xsd in the same directory where the server is running, our xsd files are locate in a different directory. The server core dumps because it could not find these xsd files. We have tried to set the property fgXercesSchemaExternalSchemaLocation with the path the xsd located on. This thus not help. Our question : Is it possible to tell the parser in with directory the xsd are located thanks Johan den Boer Software developper Dutch railways ------------------------------------------------------------------------------------------ Deze e-mail, inclusief eventuele bijlage(n), is uitsluitend bestemd voor gebruik door de geadresseerde(n). Indien u dit bericht abusievelijk heeft ontvangen, mag de informatie daarvan niet worden gebruikt of openbaar gemaakt, noch aan derden worden verstrekt. Wij verzoeken u om in dat geval direct contact op te nemen met de afzender en de e-mail te vernietigen. This e-mail, including any appendix or appendices, is intended solely for use by the addressee(s). If you have received this message in error, the information it contains may not be used or disclosed, nor may it be revealed to third parties. In that case, please contact the sender immediately and destroy the e-mail. From beddoes at intient.com Tue Feb 13 01:47:43 2007 From: beddoes at intient.com (Bradley Beddoes) Date: Sun Oct 11 15:33:52 2009 Subject: [xsd-users] XSD path location In-Reply-To: References: Message-ID: <45D15F0F.3050608@intient.com> Hi Johan, If I am understanding your requirements correctly have a look at creating your own implementation of DOMEntityResolver and assigning this to your parser, in that way you can write it to fetch resources from whatever location on your server you choose to. NB: This is for DOMBuilder there are similar resolvers you can implement for the other types of Xerces parser. regards, Bradley -- Bradley Beddoes Lead Software Architect http://intient.com Intient - "Open Source, Open Standards" Boer den, Johan J (NSC) wrote: > Hi, > > We have this problem : In our xml message there is a xsd filename > specified. Our server who parse this xml message must have the xsd in > the same directory where the server is running, our xsd files are locate > in a different directory. The server core dumps because it could not > find these xsd files. We have tried to set the property > fgXercesSchemaExternalSchemaLocation with the path the xsd located on. > This thus not help. Our question : Is it possible to tell the parser in > with directory the xsd are located > > thanks > > Johan den Boer > Software developper Dutch railways > > > ------------------------------------------------------------------------------------------ > Deze e-mail, inclusief eventuele bijlage(n), is uitsluitend bestemd voor gebruik door de > geadresseerde(n). Indien u dit bericht abusievelijk heeft ontvangen, mag de informatie > daarvan niet worden gebruikt of openbaar gemaakt, noch aan derden worden > verstrekt. Wij verzoeken u om in dat geval direct contact op te nemen met de > afzender en de e-mail te vernietigen. > > This e-mail, including any appendix or appendices, is intended solely for use by the > addressee(s). If you have received this message in error, the information it contains > may not be used or disclosed, nor may it be revealed to third parties. In that case, > please contact the sender immediately and destroy the e-mail. From boris at codesynthesis.com Tue Feb 13 01:39:51 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] XSD path location In-Reply-To: References: Message-ID: <20070213063951.GA8849@karelia> Hi Johan, Boer den, Johan J (NSC) writes: > We have this problem : In our xml message there is a xsd filename > specified. Our server who parse this xml message must have the xsd in > the same directory where the server is running, our xsd files are locate > in a different directory. The server core dumps because it could not > find these xsd files. We have tried to set the property > fgXercesSchemaExternalSchemaLocation with the path the xsd located on. > This thus not help. Our question : Is it possible to tell the parser in > with directory the xsd are located You need to specify the absolute path of the schema for this property. Otherwise it is treated as being relative to the instance. See this FAQ entry for more information: http://www.codesynthesis.com/projects/xsd/documentation/cxx/tree/faq/#2.4 Also, if your application is parsing multiple instances, it could make sense to cache the grammar and avoid re-parsing it every time, as described in this article: http://www-128.ibm.com/developerworks/webservices/library/x-xsdxerc.html hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070213/58919b61/attachment.pgp From beddoes at intient.com Tue Feb 13 02:10:51 2007 From: beddoes at intient.com (Bradley Beddoes) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] XSD path location In-Reply-To: References: Message-ID: <45D1647B.7050409@intient.com> Hi, I have CC this to the list for others. Yes of course with a resolver you can do whatever you want. When the resolver function is called it gives you the the schema location amongst other details and you could in your code choose to trust that location or go and load some other resource completely maybe based on some lookup map you have created internally or any other way you choose to implement it. Of course this assumes your using Xerces directly to create DOMDocument and then feeding that to XSD for unmarshalling but this is how I tend to work anyway and our resource resolver works really well in the same type of situation you have mentioned below. regards, Bradley -- Bradley Beddoes Lead Software Architect http://intient.com Intient - "Open Source, Open Standards" Boer den, Johan J (NSC) wrote: > Hi, > > Thanks for your reply. The problem is that there is already a xsd name > present. We have to add in the xml message the absolute path before the > xsd. Is it possible to do that. > > For example : > > Xsi:schemaLocation="http://schemaserver/schemas/1.0 ORDER.xsd" > > Should be changed to > > Xsi:schemaLocation="http://schemaserver/schemas/1.0 > /path/to/xsd/ORDER.xsd" > > regards > > Johan > > -----Oorspronkelijk bericht----- > Van: Bradley Beddoes [mailto:beddoes@intient.com] > Verzonden: dinsdag 13 februari 2007 7:48 > Aan: Boer den, Johan J (NSC) > CC: xsd-users@codesynthesis.com > Onderwerp: Re: [xsd-users] XSD path location > > Hi Johan, > If I am understanding your requirements correctly have a look at > creating your own implementation of DOMEntityResolver and assigning this > to your parser, in that way you can write it to fetch resources from > whatever location on your server you choose to. > > NB: This is for DOMBuilder there are similar resolvers you can implement > for the other types of Xerces parser. > > regards, > Bradley > -- > Bradley Beddoes > Lead Software Architect > > http://intient.com > Intient - "Open Source, Open Standards" > > Boer den, Johan J (NSC) wrote: >> Hi, >> >> We have this problem : In our xml message there is a xsd filename >> specified. Our server who parse this xml message must have the xsd in >> the same directory where the server is running, our xsd files are >> locate in a different directory. The server core dumps because it >> could not find these xsd files. We have tried to set the property >> fgXercesSchemaExternalSchemaLocation with the path the xsd located on. >> This thus not help. Our question : Is it possible to tell the parser >> in with directory the xsd are located >> >> thanks >> >> Johan den Boer >> Software developper Dutch railways >> >> >> ---------------------------------------------------------------------- >> -------------------- Deze e-mail, inclusief eventuele bijlage(n), is >> uitsluitend bestemd voor gebruik door de geadresseerde(n). Indien u >> dit bericht abusievelijk heeft ontvangen, mag de informatie daarvan >> niet worden gebruikt of openbaar gemaakt, noch aan derden worden >> verstrekt. Wij verzoeken u om in dat geval direct contact op te nemen >> met de afzender en de e-mail te vernietigen. >> >> This e-mail, including any appendix or appendices, is intended solely >> for use by the addressee(s). If you have received this message in >> error, the information it contains may not be used or disclosed, nor >> may it be revealed to third parties. In that case, please contact the > sender immediately and destroy the e-mail. > > ------------------------------------------------------------------------------------------ > Deze e-mail, inclusief eventuele bijlage(n), is uitsluitend bestemd voor gebruik door de > geadresseerde(n). Indien u dit bericht abusievelijk heeft ontvangen, mag de informatie > daarvan niet worden gebruikt of openbaar gemaakt, noch aan derden worden > verstrekt. Wij verzoeken u om in dat geval direct contact op te nemen met de > afzender en de e-mail te vernietigen. > > This e-mail, including any appendix or appendices, is intended solely for use by the > addressee(s). If you have received this message in error, the information it contains > may not be used or disclosed, nor may it be revealed to third parties. In that case, > please contact the sender immediately and destroy the e-mail. > From boris at codesynthesis.com Tue Feb 13 02:31:02 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] XSD path location In-Reply-To: <45D1647B.7050409@intient.com> References: <45D1647B.7050409@intient.com> Message-ID: <20070213073102.GC8849@karelia> Hi Johan, Bradley Beddoes writes: > Of course this assumes your using Xerces directly to create DOMDocument > and then feeding that to XSD for unmarshalling You can find a sample code for doing this on the wiki: http://wiki.codesynthesis.com/Tree/FAQ You will just need to modify it to plug in your custom entity resolver. hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070213/cf469544/attachment.pgp From Hans.Loyen at ns.nl Tue Feb 13 02:58:32 2007 From: Hans.Loyen at ns.nl (Loyen, Hans H (NSC)) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] Schema server Message-ID: Hi, We are thinking about running our own schema server. What is the best way to do this on a Red Hat Linux platform? thanks Hans Loyen ------------------------------------------------------------------------------------------ Deze e-mail, inclusief eventuele bijlage(n), is uitsluitend bestemd voor gebruik door de geadresseerde(n). Indien u dit bericht abusievelijk heeft ontvangen, mag de informatie daarvan niet worden gebruikt of openbaar gemaakt, noch aan derden worden verstrekt. Wij verzoeken u om in dat geval direct contact op te nemen met de afzender en de e-mail te vernietigen. This e-mail, including any appendix or appendices, is intended solely for use by the addressee(s). If you have received this message in error, the information it contains may not be used or disclosed, nor may it be revealed to third parties. In that case, please contact the sender immediately and destroy the e-mail. From boris at codesynthesis.com Tue Feb 13 02:53:58 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] Schema server In-Reply-To: References: Message-ID: <20070213075358.GD8849@karelia> Hi Hans, Loyen, Hans H (NSC) writes: > We are thinking about running our own schema server. > What is the best way to do this on a Red Hat Linux platform? It depends what you mean by a schema server. Can you explain in a little bit more detail what you are trying to achieve? -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070213/dfbff973/attachment.pgp From boris at codesynthesis.com Tue Feb 13 03:54:56 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] Schema server In-Reply-To: References: <20070213075358.GD8849@karelia> Message-ID: <20070213085456.GE8849@karelia> Hi Hans, I've CC'ed xsd-users so that others can benefit from this information. Please keep xsd-users in the CC list in your future replies. Loyen, Hans H (NSC) writes: > We have created a number of nested xsd-files which are used on a > interfaces between some systems. In the xsd-files there is a reference > to the schemaLocation. Until now we saved the xsd's on the local > filesystem. All our systems have to do so. It must be possible to get > them from a schema server like "http://www.w3.org/2001/XMLSchema". Maybe > I am not using the right terms here, but I hope that you do understand > me now. Any http server would do (e.g., apache). Note, however, that if you are parsing a lot of XML documents and every time the parser has to fetch the schema over the network, then you can end up with a pretty poor performance. One way to address this would be to cache the schema. > > Top of one of the xsd-files > > > - targetNamespace="http://schemaserver/schemas/1.0/ik_tds_dmt" > xmlns:xs="http://www.w3.org/2001/XMLSchema" > xmlns:ik_tds_dmt="http://schemaserver/schemas/1.0/ik_tds_dmt" > xmlns:ik_vprod="http://schemaserver/schemas/1.0/ik_vprod" > xmlns:ik_dmt="http://schemaserver/schemas/1.0/ik_dmt" > attributeFormDefault="qualified" elementFormDefault="qualified" > version="1.0"> > - > CVS Id: $Id: TDS_DOMAIN_TYPES.xsd,v 1.13 2007/02/12 > 15:45:57 hans Exp $ Hier worden de domeinen beschreven, die binnen de > TicketDistributionService worden gehanteerd. > > schemaLocation="INET_DOMAIN_TYPES.xsd" /> > Message-ID: Hi, I thought that we needed a special server for this. But I now understand that it is enough to have the xsd's available as text document on the apache server!?. We will try this. Thanks a lot Hans Loyen -----Oorspronkelijk bericht----- Van: Boris Kolpackov [mailto:boris@codesynthesis.com] Verzonden: dinsdag 13 februari 2007 9:55 Aan: Loyen, Hans H (NSC) CC: xsd-users@codesynthesis.com Onderwerp: Re: [xsd-users] Schema server Hi Hans, I've CC'ed xsd-users so that others can benefit from this information. Please keep xsd-users in the CC list in your future replies. Loyen, Hans H (NSC) writes: > We have created a number of nested xsd-files which are used on a > interfaces between some systems. In the xsd-files there is a reference > to the schemaLocation. Until now we saved the xsd's on the local > filesystem. All our systems have to do so. It must be possible to get > them from a schema server like "http://www.w3.org/2001/XMLSchema". > Maybe I am not using the right terms here, but I hope that you do > understand me now. Any http server would do (e.g., apache). Note, however, that if you are parsing a lot of XML documents and every time the parser has to fetch the schema over the network, then you can end up with a pretty poor performance. One way to address this would be to cache the schema. > > Top of one of the xsd-files > > > - targetNamespace="http://schemaserver/schemas/1.0/ik_tds_dmt" > xmlns:xs="http://www.w3.org/2001/XMLSchema" > xmlns:ik_tds_dmt="http://schemaserver/schemas/1.0/ik_tds_dmt" > xmlns:ik_vprod="http://schemaserver/schemas/1.0/ik_vprod" > xmlns:ik_dmt="http://schemaserver/schemas/1.0/ik_dmt" > attributeFormDefault="qualified" elementFormDefault="qualified" > version="1.0"> > - > CVS Id: $Id: TDS_DOMAIN_TYPES.xsd,v 1.13 > 2007/02/12 > 15:45:57 hans Exp $ Hier worden de domeinen beschreven, die binnen de > TicketDistributionService worden gehanteerd. > > schemaLocation="INET_DOMAIN_TYPES.xsd" /> > How easy would it be to support Fast Infoset? How about a different binary format that requires knowledge of the schema structure? (I already know about the low-level custom streaming. It's nice, but I need to investigate formats that preserve the structure. Fast Infoset is one possibility, but I am considering other formats, too.) -- Ray Lischner From boris at codesynthesis.com Wed Feb 14 09:25:29 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] Fast InfoSet or other binary format? In-Reply-To: References: Message-ID: <20070214142529.GA15313@karelia> Hi Ray, Ray Lischner writes: > How easy would it be to support Fast Infoset? How about a different > binary format that requires knowledge of the schema structure? (I > already know about the low-level custom streaming. It's nice, but > I need to investigate formats that preserve the structure. Fast > Infoset is one possibility, but I am considering other formats, too.) By structure I assume you mean some sort of type information in the broadest sense of this word (e.g., XML tags are type information). We can then divide all formats into two categories: the ones that are equivalent to or contain less type information than XML. Fast Infoset is one such format. The second category of formats require type information that is not available in XML so one would need access to XML Schema. I think the first category of formats is best handled at XML parsing level by either emulating SAX events or building DOM documents directly (or both: SAX for parsing and DOM for serialization). The nice side of this approach is that it is not vocabulary-specific so the same code can used for different things. I think it should be pretty straightforward sans the complexity of the format. For the second category of formats I don't see any other way than writing your own code generator. This should also be quite straight- forward from the code generation side. We can help with either type of work. hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070214/a51655db/attachment.pgp From th.mueller at weisang.com Thu Feb 15 10:04:41 2007 From: th.mueller at weisang.com (=?iso-8859-1?Q?Thomas_M=FCller?=) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] Bug using INF as a default value Message-ID: <001701c75112$9f11e600$0d01a8c0@igb.weisang.com> Hi Boris, just found an issue in XSD 2.3.1, when using an INF as a default value (using VC8): For instance in this case: Using dummy::maximum::default_value() then returns an uninitialized value. Just set a breakpoint in libxsd\xsd\cxx\tree\traits.txx (line 355) to see the issue. It seems to me that at least the cases for INF, -INF and NaN have to be handled separately. I did not try 'true' or 'false' for double values, but this could also be a - minor - issue. Best regards, Thomas From boris at codesynthesis.com Thu Feb 15 10:32:28 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] Bug using INF as a default value In-Reply-To: <001701c75112$9f11e600$0d01a8c0@igb.weisang.com> References: <001701c75112$9f11e600$0d01a8c0@igb.weisang.com> Message-ID: <20070215153228.GA31292@karelia> Hi Thomas, Thomas M?ller writes: > just found an issue in XSD 2.3.1, when using an INF as a default value Yes, we've added support for INF/-INF and NAN in the C++/Parser mapping first to see how well std::numeric_limits are supported across compilers. The C++/Tree mapping is going to support this in 2.4.0. I can also send you the fix for 2.3.1 - it's just a couple of files in libxsd. > I did not try 'true' or 'false' for double values, but this could > also be a - minor - issue. You mean 'true' and 'false' literals for boolean, right? They are supported in 2.3.1. Thanks for reporting this! -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070215/7abf25dd/attachment.pgp From th.mueller at weisang.com Thu Feb 15 10:53:33 2007 From: th.mueller at weisang.com (=?iso-8859-1?Q?Thomas_M=FCller?=) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] Bug using INF as a default value In-Reply-To: <20070215153228.GA31292@karelia> References: <001701c75112$9f11e600$0d01a8c0@igb.weisang.com> <20070215153228.GA31292@karelia> Message-ID: <002801c75119$7278f370$0d01a8c0@igb.weisang.com> Hi Boris, > > > just found an issue in XSD 2.3.1, when using an INF as a > default value > > Yes, we've added support for INF/-INF and NAN in the > C++/Parser mapping first to see how well std::numeric_limits > are supported across compilers. The C++/Tree mapping is going > to support this in 2.4.0. I can also send you the fix for > 2.3.1 - it's just a couple of files in libxsd. This would be great. > > > > I did not try 'true' or 'false' for double values, but this > could also > > be a - minor - issue. > > You mean 'true' and 'false' literals for boolean, right? They > are supported in 2.3.1. I already used it for the boolean type. Works fine. What I meant is: When specifying type xs:double and setting the default value to 'false' this might also not work. On the other hand this was based on the C++ point of view (casting bool to double is fine...) , not on the schema side. I just checked it: This is no longer a valid schema definition then. So please forget this... Thanks for your fast response. Regards, Thomas From boris at codesynthesis.com Fri Feb 16 05:58:52 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] Bug using INF as a default value In-Reply-To: <002801c75119$7278f370$0d01a8c0@igb.weisang.com> References: <001701c75112$9f11e600$0d01a8c0@igb.weisang.com> <20070215153228.GA31292@karelia> <002801c75119$7278f370$0d01a8c0@igb.weisang.com> Message-ID: <20070216105852.GA6058@karelia> Hi Thomas, Thomas M?ller writes: > I can also send you the fix for 2.3.1 - it's just a couple of files > in libxsd. > > This would be great. Here are the changes: http://codesynthesis.com/~boris/tmp/libxsd-2.3.1-2.tar.gz Just copy the files into libxsd you've got with 2.3.1. Let me know if there are any problems. > What I meant is: When specifying type xs:double and setting the > default value to 'false' this might also not work. On the other > hand this was based on the C++ point of view (casting bool to > double is fine...) , not on the schema side. I just checked it: > This is no longer a valid schema definition then. > So please forget this... Right, this is not allowed in XML Schema. hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070216/c7cf7afa/attachment.pgp From rlischner at proteus-technologies.com Sun Feb 18 17:39:45 2007 From: rlischner at proteus-technologies.com (Ray Lischner) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] xsd 2.3.1: bug in code generation for restricted type Message-ID: $ xsd cxx-tree --generate-insertion bug.xsd $ g++ -c bug.cxx bug.txx:43: error: 's' has not been declared bug.txx:44: error: expected ',' or '...' before '&' token bug.txx: In function 'xsd::cxx::tree::ostream& operator<<(xsd::cxx::tree::ostream&, int)': bug.txx:46: error: 's' was not declared in this scope bug.txx:46: error: 'x' was not declared in this scope The bug is trivially obvious and trivial to fix. I attached a patch. -- Ray Lischner -------------- next part -------------- A non-text attachment was scrubbed... Name: bug.xsd Type: application/xsd Size: 428 bytes Desc: bug.xsd Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070218/0ab480e5/bug.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: list-patch Type: text/x-diff Size: 597 bytes Desc: list-patch Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070218/0ab480e5/list-patch.bin From boris at codesynthesis.com Mon Feb 19 01:28:20 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] xsd 2.3.1: bug in code generation for restricted type In-Reply-To: References: Message-ID: <20070219062820.GB13538@karelia> Hi Ray, Ray Lischner writes: > The bug is trivially obvious and trivial to fix. I attached a patch. Applied. Thanks for the test and the patch! -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070219/d44f872c/attachment.pgp From th.mueller at weisang.com Mon Feb 19 05:24:39 2007 From: th.mueller at weisang.com (=?iso-8859-1?Q?Thomas_M=FCller?=) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] Bug using INF as a default value In-Reply-To: <20070216105852.GA6058@karelia> References: <001701c75112$9f11e600$0d01a8c0@igb.weisang.com> <20070215153228.GA31292@karelia> <002801c75119$7278f370$0d01a8c0@igb.weisang.com> <20070216105852.GA6058@karelia> Message-ID: <001601c75410$2ba37110$0d01a8c0@igb.weisang.com> Hi Boris, I did some quick tests and everything seems to work fine now. The INF/-INF texts are now correctly propagated into the double values. Thanks for your fast support. Best regards, Thomas > -----Original Message----- > From: Boris Kolpackov [mailto:boris@codesynthesis.com] > Sent: Friday, February 16, 2007 11:59 AM > To: Thomas M?ller > Cc: xsd-users@codesynthesis.com > Subject: Re: [xsd-users] Bug using INF as a default value > > Hi Thomas, > > Thomas M?ller writes: > > > I can also send you the fix for 2.3.1 - it's just a couple > of files > > in libxsd. > > > > This would be great. > > Here are the changes: > > http://codesynthesis.com/~boris/tmp/libxsd-2.3.1-2.tar.gz > > Just copy the files into libxsd you've got with 2.3.1. Let me > know if there are any problems. > > > > What I meant is: When specifying type xs:double and setting the > > default value to 'false' this might also not work. On the > other hand > > this was based on the C++ point of view (casting bool to double is > > fine...) , not on the schema side. I just checked it: > > This is no longer a valid schema definition then. > > So please forget this... > > Right, this is not allowed in XML Schema. > > > hth, > -boris > From hari at cse.fau.edu Tue Feb 20 15:51:48 2007 From: hari at cse.fau.edu (Hari Kalva) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] XSD Parser Slow. Message-ID: <020e01c75530$f3571470$5a535b83@irm.ad.fau.edu> Hello, I am using the C++/Tree mapping to parse an XML document. The parser takes almost 8 seconds to parse a simple XML document with 3 elements. The schema has about 28 elements. The XSD generated code is 280 K for the cxx file and 130 K for the hxx file. The parser used to take about 3 seconds when I had about 20 elements. Even 2 seconds for a simple document is very slow. I am using XSD 2.3. I was wondering if there is a code generation option something basic I am missing. Does the structure of the schema affect this? How elements are referenced? I am new to this list so I am not sure if this has been discussed before. Thanks in advance. -hari -- Hari Kalva, Ph.D. hari@cse.fau.edu?| www.cse.fau.edu/~hari | +1 561 297 0511 From boris at codesynthesis.com Wed Feb 21 00:53:32 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] XSD Parser Slow. In-Reply-To: <020e01c75530$f3571470$5a535b83@irm.ad.fau.edu> References: <020e01c75530$f3571470$5a535b83@irm.ad.fau.edu> Message-ID: <20070221055332.GA29863@karelia> Hi Hari, Hari Kalva writes: > Hello, I am using the C++/Tree mapping to parse an XML document. The parser > takes almost 8 seconds to parse a simple XML document with 3 elements. The > schema has about 28 elements. The XSD generated code is 280 K for the cxx > file and 130 K for the hxx file. The parser used to take about 3 seconds > when I had about 20 elements. Even 2 seconds for a simple document is very > slow. Hm, that's strange. We have a benchmark with about 6000 sub-elements which performs non-optimized in about 10ms without validation and 12ms with validation. There has got to be something special about your schema and/or instance. Would it be possible for you to send it in so I can figure out what's going on? > I am using XSD 2.3. There were some optimizations in 2.3.1 so you may want to give it a try. > Does the structure of the schema affect this? There are several things you may want to check: 1. Make sure your XML instance does not reference the schema over HTTP. If that's the case and validation is enabled then the parsers has to fetch your schema every time you parse your instance. 2. Check if your schema has any large maxOccurs values. If so then you may want to replace them with "unbounded" or disable validation. Xerces-C++ performs significantly slower with large maxOccurs. 3. Disable validation by passing the xml_schema::flags::dont_validate flag to the parsing function. This way you can figure out what takes so much time: parsing or validation. hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070221/de298bbb/attachment.pgp From hari at cse.fau.edu Wed Feb 21 10:02:21 2007 From: hari at cse.fau.edu (Hari Kalva) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] XSD Parser Slow. In-Reply-To: <20070221055332.GA29863@karelia> References: <020e01c75530$f3571470$5a535b83@irm.ad.fau.edu> <20070221055332.GA29863@karelia> Message-ID: <00a401c755c9$4cb73110$5a535b83@irm.ad.fau.edu> Boris, Thanks. I had an element with 12 sub-elements each with maxOccurs of 255. I changed this to unbounded as per your suggestion and the parsing delay is gone! I haven't timed it but no noticible delays. Thanks a lot! -hari -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Wednesday, February 21, 2007 12:54 AM To: Hari Kalva Cc: xsd-users@codesynthesis.com Subject: Re: [xsd-users] XSD Parser Slow. Hi Hari, Hari Kalva writes: > Hello, I am using the C++/Tree mapping to parse an XML document. The > parser takes almost 8 seconds to parse a simple XML document with 3 > elements. The schema has about 28 elements. The XSD generated code is > 280 K for the cxx file and 130 K for the hxx file. The parser used to > take about 3 seconds when I had about 20 elements. Even 2 seconds for > a simple document is very slow. Hm, that's strange. We have a benchmark with about 6000 sub-elements which performs non-optimized in about 10ms without validation and 12ms with validation. There has got to be something special about your schema and/or instance. Would it be possible for you to send it in so I can figure out what's going on? > I am using XSD 2.3. There were some optimizations in 2.3.1 so you may want to give it a try. > Does the structure of the schema affect this? There are several things you may want to check: 1. Make sure your XML instance does not reference the schema over HTTP. If that's the case and validation is enabled then the parsers has to fetch your schema every time you parse your instance. 2. Check if your schema has any large maxOccurs values. If so then you may want to replace them with "unbounded" or disable validation. Xerces-C++ performs significantly slower with large maxOccurs. 3. Disable validation by passing the xml_schema::flags::dont_validate flag to the parsing function. This way you can figure out what takes so much time: parsing or validation. hth, -boris From Paddy.Vishnubhatt at 3leafnetworks.com Wed Feb 21 09:52:24 2007 From: Paddy.Vishnubhatt at 3leafnetworks.com (Paddy Vishnubhatt) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] XML Object to String/Text Message-ID: <7C1D552561AF0544ACC7CF6F10E4966E8A000F@chronus.3leafnetworks.corp> hi, 1. is there a simple way to get a stringified representation of the object? Like in the Java API (xmlbeans), xmlText() or even toString() which outputs a Sring representation of the given Xml Object? 2. I see that there are documented ways to create DOMDocument from which one can use DOMWriter to use writeString to get to ultimately get to the string - is there an example/sample code that I can use for/as reference. Thx v much in advance. - From boris at codesynthesis.com Wed Feb 21 10:10:49 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] XML Object to String/Text In-Reply-To: <7C1D552561AF0544ACC7CF6F10E4966E8A000F@chronus.3leafnetworks.corp> References: <7C1D552561AF0544ACC7CF6F10E4966E8A000F@chronus.3leafnetworks.corp> Message-ID: <20070221151049.GB32005@karelia> Hi Paddy, Paddy Vishnubhatt writes: > 1. is there a simple way to get a stringified representation of the > object? Like in the Java API (xmlbeans), xmlText() or even toString() > which outputs a Sring representation of the given Xml Object? You can use one of the serialization functions together with std::ostringstream. For instance, in the library example there is the this line: // Write it out. // catalog_ (std::cout, *c, map); You can replace it with something like this (also add #include ): // Write it to string. // std::ostringstream ostr; catalog_ (ostr, *c, map); std::string str = ostr.str (); // XML is in str. > 2. I see that there are documented ways to create DOMDocument from which > one can use DOMWriter to use writeString to get to ultimately get to > the string - is there an example/sample code that I can use for/as > reference. There is some sample DOM manipulation code on the Wiki, see for example 3.1 and 3.2: http://wiki.codesynthesis.com/Tree/FAQ The ostringstream way is much easier though. hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070221/ed540e46/attachment.pgp From Paddy.Vishnubhatt at 3leafnetworks.com Wed Feb 21 10:47:29 2007 From: Paddy.Vishnubhatt at 3leafnetworks.com (Paddy Vishnubhatt) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] XML Object to String/Text References: <7C1D552561AF0544ACC7CF6F10E4966E8A000F@chronus.3leafnetworks.corp> <20070221151049.GB32005@karelia> Message-ID: <7C1D552561AF0544ACC7CF6F10E4966E8A0012@chronus.3leafnetworks.corp> Thx Boris for the prompt response. ________________________________ From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Wed 2/21/2007 7:10 AM To: Paddy Vishnubhatt Cc: xsd-users@codesynthesis.com Subject: Re: [xsd-users] XML Object to String/Text Hi Paddy, Paddy Vishnubhatt writes: > 1. is there a simple way to get a stringified representation of the > object? Like in the Java API (xmlbeans), xmlText() or even toString() > which outputs a Sring representation of the given Xml Object? You can use one of the serialization functions together with std::ostringstream. For instance, in the library example there is the this line: // Write it out. // catalog_ (std::cout, *c, map); You can replace it with something like this (also add #include ): // Write it to string. // std::ostringstream ostr; catalog_ (ostr, *c, map); std::string str = ostr.str (); // XML is in str. >> In my xsd definition and compliation (i did use the --generate-serialization per yr note in the example), I don't find the catalog_ definitions/declarations. (I get an catalog_ undeclared compile error). In order to use route 1, is it a must to create a document object in the XSD definition like how you did it in library example? (xsd:element name="catalog" type="lib:catalog"/>) If so, What if you don't have a documentation declaration in xsd (I have many xsd definitions and would like to avoid creating document objects for each one of them). > 2. I see that there are documented ways to create DOMDocument from which > one can use DOMWriter to use writeString to get to ultimately get to > the string - is there an example/sample code that I can use for/as > reference. There is some sample DOM manipulation code on the Wiki, see for example 3.1 and 3.2: http://wiki.codesynthesis.com/Tree/FAQ The ostringstream way is much easier though. >> True, ostringstream is definitely the right approach but am wondering if I need to do something different w/ my xsd definitions... From boris at codesynthesis.com Wed Feb 21 11:41:39 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] XML Object to String/Text In-Reply-To: <7C1D552561AF0544ACC7CF6F10E4966E8A0012@chronus.3leafnetworks.corp> References: <7C1D552561AF0544ACC7CF6F10E4966E8A000F@chronus.3leafnetworks.corp> <20070221151049.GB32005@karelia> <7C1D552561AF0544ACC7CF6F10E4966E8A0012@chronus.3leafnetworks.corp> Message-ID: <20070221164139.GC32005@karelia> Hi Paddy, Paddy Vishnubhatt writes: > In order to use route 1, is it a must to create a document object > in the XSD definition like how you did it in library example? Yes, serialization functions (e.g., catalog_ in the example I gave) are generated only for global elements (since they are valid document roots). If you want to serialize individual objects that correspond to types defined in XML Schema then you will need to use DOM. Here is how you can do this: 1. Create DOM document using the create function from Q 3.1 in FAQ[1]: xml::dom::auto_ptr doc ( create ("example", "http://www.example.com/xmlns/example", "e")); DOMElement* root (doc->getDocumentElement ()); Use your element name, namespace and prefix. Also don't forget to call XMLPlatformUtils::Initialize (). 2. Serialize your object to the document's root element (remember to compile your schemas with --generate-serialization): my_obj& obj = ... DOMElement& root (*doc->getDocumentElement ()); root << obj; 3. Serialize the DOM document to string using code from Q 3.2: std::ostringstream ostr; serialize (ostr, *doc); std::string str = ostr.str (); As you can see, you will need to create a DOM document with the root element name of your choice. Since the object does not have this information (and an XML Schema type can be used as a type for several elements), there is no way to provide a function like to_xml_as_string. I am not sure how Java frameworks work around this. [1] http://wiki.codesynthesis.com/Tree/FAQ hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070221/55c1edfc/attachment.pgp From Paddy.Vishnubhatt at 3leafnetworks.com Wed Feb 21 11:45:46 2007 From: Paddy.Vishnubhatt at 3leafnetworks.com (Paddy Vishnubhatt) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] XML Object to String/Text References: <7C1D552561AF0544ACC7CF6F10E4966E8A000F@chronus.3leafnetworks.corp> <20070221151049.GB32005@karelia> Message-ID: <7C1D552561AF0544ACC7CF6F10E4966E8A0015@chronus.3leafnetworks.corp> w.r.t 2: There is some sample DOM manipulation code on the Wiki, see for example 3.1 and 3.2: http://wiki.codesynthesis.com/Tree/FAQ Q: Is there an API that I can generically use to create DOMDocument objects from any XSD-driven object? -- ________________________________ From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Wed 2/21/2007 7:10 AM To: Paddy Vishnubhatt Cc: xsd-users@codesynthesis.com Subject: Re: [xsd-users] XML Object to String/Text Hi Paddy, Paddy Vishnubhatt writes: > 1. is there a simple way to get a stringified representation of the > object? Like in the Java API (xmlbeans), xmlText() or even toString() > which outputs a Sring representation of the given Xml Object? You can use one of the serialization functions together with std::ostringstream. For instance, in the library example there is the this line: // Write it out. // catalog_ (std::cout, *c, map); You can replace it with something like this (also add #include ): // Write it to string. // std::ostringstream ostr; catalog_ (ostr, *c, map); std::string str = ostr.str (); // XML is in str. > 2. I see that there are documented ways to create DOMDocument from which > one can use DOMWriter to use writeString to get to ultimately get to > the string - is there an example/sample code that I can use for/as > reference. There is some sample DOM manipulation code on the Wiki, see for example 3.1 and 3.2: http://wiki.codesynthesis.com/Tree/FAQ The ostringstream way is much easier though. hth, -boris From boris at codesynthesis.com Wed Feb 21 11:54:35 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] XML Object to String/Text In-Reply-To: <7C1D552561AF0544ACC7CF6F10E4966E8A0015@chronus.3leafnetworks.corp> References: <7C1D552561AF0544ACC7CF6F10E4966E8A000F@chronus.3leafnetworks.corp> <20070221151049.GB32005@karelia> <7C1D552561AF0544ACC7CF6F10E4966E8A0015@chronus.3leafnetworks.corp> Message-ID: <20070221165435.GD32005@karelia> Hi Paddy, Paddy Vishnubhatt writes: > Q: Is there an API that I can generically use to create DOMDocument > objects from any XSD-driven object? One (easy) way would be to create a function template from the code I sent you in another email. A more elaborate method which can serialize any type via xml_schema::type (base for all generated types) is described in this message: http://www.codesynthesis.com/pipermail/xsd-users/2006-August/000501.html Note that in the latest version the "type_name_*" names were changed to "type_serializer_*". hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070221/d5fa5b8c/attachment.pgp From rlischner at proteus-technologies.com Wed Feb 21 16:15:41 2007 From: rlischner at proteus-technologies.com (Ray Lischner) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] Typo in xsd/cxx/tree/buffer.hxx Message-ID: version 2.3.1 file: xsd/cxx/tree/buffer.txx Line 97: delete the "_", that is, change "capacity_" to "capacity". (Sorry, I can't generate a patch file at work. We have a wierd environment here.) -- Ray Lischner From Paddy.Vishnubhatt at 3leafnetworks.com Wed Feb 21 23:33:40 2007 From: Paddy.Vishnubhatt at 3leafnetworks.com (Paddy Vishnubhatt) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] XML Object to String/Text References: <7C1D552561AF0544ACC7CF6F10E4966E8A000F@chronus.3leafnetworks.corp> <20070221151049.GB32005@karelia> <7C1D552561AF0544ACC7CF6F10E4966E8A0015@chronus.3leafnetworks.corp> <20070221165435.GD32005@karelia> Message-ID: <7C1D552561AF0544ACC7CF6F10E4966E8A001F@chronus.3leafnetworks.corp> Hi Boris, Thx for all the help, I could finally get the String output to work based on yr code/examples. The following is the way I could get it all to work: xml::dom::auto_ptr doc (create( // create-taken from the link you sent below. request.objectName(), "http:// ...", "e")); xercesc::DOMElement& root (*doc->getDocumentElement()); root << request; std::ostringstream ostr; serialize(ostr, *doc, "UTF-8"); // taken from the link you sent. std::string str = ostr.str(); LOG4CXX_DEBUG(logger(), str); Thx again for all the prompt help and pls keep up the good work. Feature request/suggestion: Can this all be packaged into one API? I don't know how the Java framework managed to pull this off but it is likely that they may have hidden all the above (the create() and serialize() functions and the use of ostringstream, etc) 'under the covers' and offered a 'blanket' API and called it xmlText(). If you can do the same in some near (or not so distant) future, it'll help many who're doing distributed/x-platform (XDR-like) where stringifying XML to strings and passing data is an easy means to exchange data. -- ________________________________ From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Wed 2/21/2007 8:54 AM To: Paddy Vishnubhatt Cc: Boris Kolpackov; xsd-users@codesynthesis.com Subject: Re: [xsd-users] XML Object to String/Text Hi Paddy, Paddy Vishnubhatt writes: > Q: Is there an API that I can generically use to create DOMDocument > objects from any XSD-driven object? One (easy) way would be to create a function template from the code I sent you in another email. A more elaborate method which can serialize any type via xml_schema::type (base for all generated types) is described in this message: http://www.codesynthesis.com/pipermail/xsd-users/2006-August/000501.html Note that in the latest version the "type_name_*" names were changed to "type_serializer_*". hth, -boris From boris at codesynthesis.com Thu Feb 22 01:35:35 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] Typo in xsd/cxx/tree/buffer.hxx In-Reply-To: References: Message-ID: <20070222063535.GA1425@karelia> Hi Ray, Ray Lischner writes: > version 2.3.1 > file: xsd/cxx/tree/buffer.txx > Line 97: delete the "_", that is, change "capacity_" to "capacity". Fixed. Thanks for reporting this! -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070222/b7f919a6/attachment.pgp From boris at codesynthesis.com Thu Feb 22 13:22:31 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] XML Object to String/Text In-Reply-To: <7C1D552561AF0544ACC7CF6F10E4966E8A001F@chronus.3leafnetworks.corp> References: <7C1D552561AF0544ACC7CF6F10E4966E8A000F@chronus.3leafnetworks.corp> <20070221151049.GB32005@karelia> <7C1D552561AF0544ACC7CF6F10E4966E8A0015@chronus.3leafnetworks.corp> <20070221165435.GD32005@karelia> <7C1D552561AF0544ACC7CF6F10E4966E8A001F@chronus.3leafnetworks.corp> Message-ID: <20070222182231.GA5107@karelia> Hi Paddy, Paddy Vishnubhatt writes: > Feature request/suggestion: Can this all be packaged into one API? I > don't know how the Java framework managed to pull this off but it is > likely that they may have hidden all the above (the create() and > serialize() functions and the use of ostringstream, etc) 'under the > covers' and offered a 'blanket' API and called it xmlText(). If you > can do the same in some near (or not so distant) future, it'll help > many who're doing distributed/x-platform (XDR-like) where stringifying > XML to strings and passing data is an easy means to exchange data. Thanks for the suggestion. The tricky part here is to figure out what the element name should be. In your code you used request.objectName() but that is application-specific. On the other hand, you can get pretty much all of that code (except the stringstream part) auto-generated by declaring a global element corresponding to your type. This is also right thing to do from the XML Schema perspective since your document becomes valid per the schema. We will think some more on this. thanks, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070222/a6a6af30/attachment.pgp From rlischner at proteus-technologies.com Thu Feb 22 20:02:40 2007 From: rlischner at proteus-technologies.com (Ray Lischner) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] getFoo, get_foo, foo() and setFoo, set_foo, foo(f) Message-ID: Our local style guide says we need call setters setName(x) and getters getName() instead of name(x) and name(). How feasible is it to add to xsd some user-configurability of member function names? -- Ray Lischner, Proteus Technologies From boris at codesynthesis.com Fri Feb 23 12:18:22 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] getFoo, get_foo, foo() and setFoo, set_foo, foo(f) In-Reply-To: References: Message-ID: <20070223171822.GA17681@karelia> Hi Ray, Ray Lischner writes: > Our local style guide says we need call setters setName(x) and > getters getName() instead of name(x) and name(). > > How feasible is it to add to xsd some user-configurability of > member function names? We were thinking about something like this but for mangling schema type names. The idea was to provide an option with which one can specify a regex that is used to transform names. Another option would allow one to select from a set of predefined styles (e.g., smalltalk, stdcxx, and camelcase or something along these lines). I guess it would also make sense to do the same for accessors and modifiers. It is a bit easier with types because we already have a special pass over the semantic graph that checks for name clashes and assigns names. With function names we will need to still add this infrastructure (it is partially there but does not distinguish between accessors and modifiers). I can give this a shot in a couple of weeks. hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070223/5d8ee534/attachment.pgp From dkelly at yahoo.com Tue Feb 27 09:21:19 2007 From: dkelly at yahoo.com (Dwight Kelly) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] Microsoft's Print Schema Message-ID: <407334.21071.qm@web37510.mail.mud.yahoo.com> Hello, I tried to generate cxx-parser bindings for Microsoft's XPS Print Schema and received the following error message from xsd: Error Schema Representation Constraint: Namespace 'http://www.w3.org/2001/XMLSchema-instance' is referenced without declaration The Print Schema can be downloaded from: http://www.microsoft.com/whdc/xps/printschema.mspx Can someone tell me how to solve this problem? Thank you, Dwight Kelly From boris at codesynthesis.com Tue Feb 27 10:15:06 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] Microsoft's Print Schema In-Reply-To: <407334.21071.qm@web37510.mail.mud.yahoo.com> References: <407334.21071.qm@web37510.mail.mud.yahoo.com> Message-ID: <20070227151506.GA3281@karelia> Hi Dwight, Dwight Kelly writes: > Hello, I tried to generate cxx-parser bindings for Microsoft's XPS > Print Schema and received the following error message from xsd: > > Error Schema Representation Constraint: Namespace > 'http://www.w3.org/2001/XMLSchema-instance' is referenced without > declaration This is the part of the schema that causes the error: It refers to the xsi:type special attribute but there is no declarations for it. I am not sure whether it is legal or not so I am going to as on the xmlschema-dev mailing list. I also tested this schema with a number of schema processors. Xerces-J accepts the schema while Xerces-C++, Jing, and MSV all flag it as invalid. I am not sure what exactly the author of the schema wanted to achieve with this. Most likely they wanted the CT_Value type (the only type that references this group) to be abstract. This is much easier achieved with the abstract attribute: So I suggest that you comment AG_ValueAttributes out and change the CT_Value to be as above. After these changes I could compile the schema without any errors. hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070227/bdfea8b1/attachment.pgp From rlischner at proteus-technologies.com Wed Feb 28 10:17:10 2007 From: rlischner at proteus-technologies.com (Ray Lischner) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] build problems Message-ID: I am trying to build xsd from source. I am trying to use the installed ACE, Boost, and Xerces libraries. I supply the necessary -I options for C++ preprocessor options and -L options for C++ linker options. The make stops after processing/restriction/processor.cxx with no error message. I tried to cd into the xsd directory and run make, and then I get an error: No rule to make target: -lboost_filesystem In the past, I've always used the development version of Boost, ACE, and Xerces, but this time I'm trying to use the official, corporate, installed, and supported libraries. With the fancy build system, I can't debug or workaround this problem easily, and can't proceed. -- Ray Lischner, Proteus Technologies From rlischner at proteus-technologies.com Wed Feb 28 13:07:56 2007 From: rlischner at proteus-technologies.com (Ray Lischner) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] virtual insertion/extraction Message-ID: When I use --generate-polymorphic, xsd warns me that stream insertion/extraction operators are not yet polymorphism-aware. This is not surprising because these operators are templated, and virtual template member functions are not allowed. Nonetheless, is there some way to write virtual insertion functions? (Extraction is less important to us right now.) All I can think of is to force a specific template argument to xsd::cxx::tree::ostream, but even that requires that I be able to specify a block of code to add to every generated class. Any suggestions on how I might proceed? -- Ray Lischner, Proteus Technologies From boris at codesynthesis.com Wed Feb 28 13:36:08 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] build problems In-Reply-To: References: Message-ID: <20070228183608.GA14248@karelia> Hi Ray, Ray Lischner writes: > I am trying to build xsd from source. I am trying to use the installed > ACE, Boost, and Xerces libraries. In order to build the XSD translator itself you will need source distribution of Xerces-C++ because XSD uses some of the internal headers that are not available in the installed version. You can use the installed version to build the generated code though. > I supply the necessary -I options for C++ preprocessor options > and -L options for C++ linker options. The make stops after > processing/restriction/processor.cxx with no error message. Hm, that's strange. Are those libraries installed in a place where tools would look by default (e.g., /usr or /usr/local)? Do you supply those preprocessor and linker options via the extra option prompts? > I tried to cd into the xsd directory and run make, and then I get > an error: > > No rule to make target: -lboost_filesystem I think I know what's going on. The build system extracts library search paths from the compiler and adds them to make's vpath. It does not do this for the paths that were supplied for the extra linker options flag. That's why make complains about -lboost_filesystem. I will try to resolve this and will send you the fix, hopefully in a few hours. hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070228/ae570835/attachment.pgp From boris at codesynthesis.com Wed Feb 28 14:42:22 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] build problems In-Reply-To: <20070228183608.GA14248@karelia> References: <20070228183608.GA14248@karelia> Message-ID: <20070228194222.GB14248@karelia> Hi Ray, Boris Kolpackov writes: > I think I know what's going on. The build system extracts library > search paths from the compiler and adds them to make's vpath. It > does not do this for the paths that were supplied for the extra > linker options flag. That's why make complains about > -lboost_filesystem. I will try to resolve this and will send you > the fix, hopefully in a few hours. The fix is ready. You will need to get build-0.2.3.b1: http://codesynthesis.com/~boris/tmp/build-0.2.3.b1.tar.bz2 After installing it you will need to re-configure all the projects where you provided the -L options. Or you can just delete build/cxx/configuration-dynamic.make to save time. Let me know if there are any problems. -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070228/e9e0fe3b/attachment.pgp From boris at codesynthesis.com Wed Feb 28 16:15:03 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] virtual insertion/extraction In-Reply-To: References: Message-ID: <20070228211503.GD14248@karelia> Hi Ray, Ray Lischner writes: > When I use --generate-polymorphic, xsd warns me that stream > insertion/extraction operators are not yet polymorphism-aware. > This is not surprising because these operators are templated, > and virtual template member functions are not allowed. Nonetheless, > is there some way to write virtual insertion functions? (Extraction > is less important to us right now.) You are right, the current architecture with templates does not work well for the polymorphic case. The reason for this somewhat elaborate template-based architecture is (1) to allow for user- defined streams and (2) to make insertion and extraction efficient. A more straightforward architecture would be to define a stream interface which can be implemented for different formats. The drawback of this approach is that it will require a virtual function call for every insertion and extraction, even for simple things like int or bool. I am not sure whether it would be a significant overhead or not but I didn't like it then and I am not sure I like it now ;-). The only other option that I can think of right now is to generate hard-wired insertion operators and extraction c-tors with the stream type (or types) provided by the user via a command line option. This approach is also not ideal since it is not clear how to provide such hard-wired extraction c-tors for built-in types which are pre-defined in the runtime library. Also note that we are not using the virtual function mechanism for things like parsing and serialization in order to keep things modular. In case of XML, we generate type factory/serialization maps that are used to find the right type (there is no other way for parsing and serialization is using the same method for symmetry and modularity). I was planning to use the same approach for binary insertion and extraction. The reason why templates won't do here is because we need to store pointers to actual functions in those maps. Maybe the user could provide the stream types for which such functions be instantiated and registered? I will need to think some more on this. -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070228/10bebbc3/attachment.pgp