From christian at gsvitec.com Wed Jan 21 08:40:38 2015 From: christian at gsvitec.com (Christian Sell) Date: Wed Jan 21 08:40:30 2015 Subject: [xsde-users] c++/Hybrid: element names and line numbers Message-ID: <000e01d0357f$d76036b0$8620a410$@gsvitec.com> Hello, sorry if I overlooked something - this should be a rather common issue: we need access to the element name under which a given XSD type was parsed, as well as the line number in the XML document. The former for resolution of elements in substitution groups (I know I can define extra types), the latter for error reporting. Thanks, Christian From christian at gsvitec.com Thu Jan 22 08:43:23 2015 From: christian at gsvitec.com (Christian Sell) Date: Thu Jan 22 08:43:12 2015 Subject: [xsde-users] generated parser crashes Message-ID: <002501d03649$641a6bb0$2c4f4310$@gsvitec.com> Hello, we have a parser generated from a valid schema, and a valid XML document. When the parser is invoked on the document, it crashes with a segmentation fault. What gives? Also, please have a look at the other question I posted a few days ago regarding line numbers Regards, Christian From boris at codesynthesis.com Thu Jan 22 08:38:44 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Jan 22 08:47:33 2015 Subject: [xsde-users] Re: generated parser crashes In-Reply-To: <002501d03649$641a6bb0$2c4f4310$@gsvitec.com> References: <002501d03649$641a6bb0$2c4f4310$@gsvitec.com> Message-ID: Hi Christian, Christian Sell writes: > we have a parser generated from a valid schema, and a valid XML document. > When the parser is invoked on the document, it crashes with a segmentation > fault. What gives? If you can send a test case that reproduces the problem, I can take a look. You can send it off-list if you want to keep it private. Without that, it is hard to say. Boris From boris at codesynthesis.com Thu Jan 22 09:01:48 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Jan 22 09:10:36 2015 Subject: [xsde-users] c++/Hybrid: element names and line numbers In-Reply-To: <000e01d0357f$d76036b0$8620a410$@gsvitec.com> References: <000e01d0357f$d76036b0$8620a410$@gsvitec.com> Message-ID: Hi Christian, Christian Sell writes: > sorry if I overlooked something - this should be a rather common issue: Not really, not for XSD/e anyway. Generally, people who use XSD/e want as small a footprint as possible so "syntactic sugar" like this is discarded as quickly as possible. This is also a good example of power and flexibility of XSD compared to XSD/e where this is much easier to achieve (at the cost of footprint, of course). > we need access to the element name under which a given XSD type was > parsed, as well as the line number in the XML document. This information is only available during parsing. If you want to store it in the object model, then you will have to do two things: 1. Customize the object model types to include data members to store this information (Section 4.9, "Customizing the Object Model"). 2. Cusotmize the corresponding parser implementations to extract this information and store it in the object model (Section 6.1, "Customizing Parsers and Serializers"). This is not too difficult to implement for a few types but if you need this for your entire object model, it will be daunting. Some more details on #2 above: the information you are looking for is available in the parsing context (see libxsde/xsde/cxx/parser/context.hxx). There are accessors for element name/namespace. For line/column, you will need to get the underlying Expat parser (xml_parser()) and query it for this info (XML_GetCurrentLineNumber(), XML_GetCurrentColumnNumber()). See also this earlier post for some more details: http://www.codesynthesis.com/pipermail/xsde-users/2008-October/000081.html Boris From christian at gsvitec.com Thu Jan 22 09:50:18 2015 From: christian at gsvitec.com (Christian Sell) Date: Thu Jan 22 09:50:07 2015 Subject: AW: [xsde-users] c++/Hybrid: element names and line numbers In-Reply-To: References: <000e01d0357f$d76036b0$8620a410$@gsvitec.com> Message-ID: <003201d03652$bd9a7960$38cf6c20$@gsvitec.com> Hello, > This is not too difficult to implement for a few types but if you need this for your entire object model, it will be daunting. That's the impression I took away from my initial investigation, and I agree that it is impractical, as the parser customization has to be written for each individual type. And of course, we need error reporting at every point. We have a large dependency on XSD(/e) at development time for code generation, and some at runtime. We could move (back, argh!) to XSD for the development part, and stick with XSD/e for the runtime. We just wanted to avoid having to maintain 2 tools. Regards, Christian From boris at codesynthesis.com Thu Jan 22 10:40:59 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Jan 22 10:49:47 2015 Subject: [xsde-users] c++/Hybrid: element names and line numbers In-Reply-To: <003201d03652$bd9a7960$38cf6c20$@gsvitec.com> References: <000e01d0357f$d76036b0$8620a410$@gsvitec.com> <003201d03652$bd9a7960$38cf6c20$@gsvitec.com> Message-ID: Hi Christian, Christian Sell writes: > We have a large dependency on XSD(/e) at development time for code > generation, and some at runtime. We could move (back, argh!) to XSD for the > development part, and stick with XSD/e for the runtime. We just wanted to > avoid having to maintain 2 tools. Yes, that sounds hairy. If you only need access to this information during development, then maybe your could hack something up directly in libxsde? Maybe store this information in a global variable or some such? Boris From christian at gsvitec.com Thu Jan 22 11:31:39 2015 From: christian at gsvitec.com (Christian Sell) Date: Thu Jan 22 11:31:28 2015 Subject: AW: [xsde-users] c++/Hybrid: element names and line numbers In-Reply-To: References: <000e01d0357f$d76036b0$8620a410$@gsvitec.com> <003201d03652$bd9a7960$38cf6c20$@gsvitec.com> Message-ID: <000a01d03660$e65d2a10$b3177e30$@gsvitec.com> I just looked at our code base and have to conclude that moving to XSD is a non-option, given all the dependencies on XSD/e classes and APIs. Hacking may be an option. I just wonder why there isn't flexibility to implement this in a clean way. Since the XSD/e Parser is event-driven, it should have access to everything. And the XSD/e Hybrid name sounds as if there was a lower event-driven layer into which one could kick down.. -----Urspr?ngliche Nachricht----- Von: Boris Kolpackov [mailto:boris@codesynthesis.com] Gesendet: Donnerstag, 22. Januar 2015 16:41 An: Christian Sell Cc: xsde-users@codesynthesis.com Betreff: Re: [xsde-users] c++/Hybrid: element names and line numbers Hi Christian, Christian Sell writes: > We have a large dependency on XSD(/e) at development time for code > generation, and some at runtime. We could move (back, argh!) to XSD > for the development part, and stick with XSD/e for the runtime. We > just wanted to avoid having to maintain 2 tools. Yes, that sounds hairy. If you only need access to this information during development, then maybe your could hack something up directly in libxsde? Maybe store this information in a global variable or some such? Boris From boris at codesynthesis.com Mon Jan 26 08:52:37 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Jan 26 09:01:24 2015 Subject: [xsde-users] c++/Hybrid: element names and line numbers In-Reply-To: <000a01d03660$e65d2a10$b3177e30$@gsvitec.com> References: <000e01d0357f$d76036b0$8620a410$@gsvitec.com> <003201d03652$bd9a7960$38cf6c20$@gsvitec.com> <000a01d03660$e65d2a10$b3177e30$@gsvitec.com> Message-ID: Hi Christian, Christian Sell writes: > Since the XSD/e Parser is event-driven, it should have access to everything. And it does, see my previous email. > And the XSD/e Hybrid name sounds as if there was a lower event-driven > layer into which one could kick down.. Yes there is, called C++/Parser. Again, see my previous email (I am starting to get the impression you actually haven't read it). > I just wonder why there isn't flexibility to implement this in a > clean way. Indeed there is! It involves customizing your object model to include data members to store the extra data. And then customizing the (C++/Parser) parser implementations to copy this data into the object model. It is very clean. Just not very easy. What would make it easy is support for code generation plugins. I've had this idea for XSD (e.g., to generate "visitors") but it will work very well here as well. Boris From christian at gsvitec.com Mon Jan 26 09:10:38 2015 From: christian at gsvitec.com (Christian Sell) Date: Mon Jan 26 09:10:18 2015 Subject: AW: [xsde-users] c++/Hybrid: element names and line numbers In-Reply-To: References: <000e01d0357f$d76036b0$8620a410$@gsvitec.com> <003201d03652$bd9a7960$38cf6c20$@gsvitec.com> <000a01d03660$e65d2a10$b3177e30$@gsvitec.com> Message-ID: <001001d03971$dca1e6f0$95e5b4d0$@gsvitec.com> > What would make it easy is support for code generation plugins. > I've had this idea for XSD (e.g., to generate "visitors") but it will work very well here as well. THAT's what I call a clean solution, and what I have been aiming at all the time. Having to write identical parser customizations for each class is a non-solution for me (or rather, a totally unclean one in my definition of "unclean"), that's why I never jumped on it. Christian From christian at gsvitec.com Sat Jan 31 08:18:15 2015 From: christian at gsvitec.com (Christian Sell) Date: Sat Jan 31 08:18:18 2015 Subject: [xsde-users] Building latest repository version Message-ID: <185675624.244981.1422710295287.JavaMail.open-xchange@ptangptang.store> Hello, I am trying to build the latest XSD/e version from the git repository. I have cloned, built and installed (where applicable) the build, cli, libcutl and libxsd-frontend projects. Now that I am trying to build xsde proper, I am getting hte following error message: In file included from /home/cse/work/git/codesyth/xsde/xsde/cxx/elements.hxx:15:0, from /home/cse/work/git/codesyth/xsde/xsde/cxx/elements.cxx:5: ./xsd-frontend/semantic-graph.hxx:19:55: fatal error: xsd-frontend/semantic-graph/fundamental.hxx: No such file or directory #include When lloking into the xsd-frontend/semantic-graph directory, I can see a file "fundamental.hxx.m4" only. There are other header files without the m4 postfix, so I assume something went wrong while building xsd-frontend. Can someone point out what that is? Thanks Christian From christian at gsvitec.com Sat Jan 31 22:14:48 2015 From: christian at gsvitec.com (Christian Sell) Date: Sat Jan 31 22:14:51 2015 Subject: [xsde-users] Building latest repository version In-Reply-To: <185675624.244981.1422710295287.JavaMail.open-xchange@ptangptang.store> References: <185675624.244981.1422710295287.JavaMail.open-xchange@ptangptang.store> Message-ID: <103941629.286980.1422760488438.JavaMail.open-xchange@ptangptang.store> never mind, after cleaning and rebuilding the problem was gone. However, there is a new one: after successfuly building the xsde compiler and library, the generated parser is no longer able to parse the input xml documents. It quits with a validation error (unexpected element encountered), even though these documents are perfectly valid against the schema from which the parser was generated. Interestingly, the places where validation fails all have to do with recursive structures. It was exactly these structures which weren't parsed at all by xsde 3.2 (or sometimes it crashed). I received a pre-built windows 3.3.0.a7 distro from boris last week, which worked ok against the same schema and documents. However, the linux buld I am trying to put together now doesn't. Whats's going wrong?? Regards, Christian > Christian Sell hat am 31. Januar 2015 um 14:18 > geschrieben: > > > Hello, > > I am trying to build the latest XSD/e version from the git repository. I have > cloned, built and installed (where applicable) the build, cli, libcutl and > libxsd-frontend projects. Now that I am trying to build xsde proper, I am > getting hte following error message: > > In file included from > /home/cse/work/git/codesyth/xsde/xsde/cxx/elements.hxx:15:0, > from /home/cse/work/git/codesyth/xsde/xsde/cxx/elements.cxx:5: > ./xsd-frontend/semantic-graph.hxx:19:55: fatal error: > xsd-frontend/semantic-graph/fundamental.hxx: No such file or directory > #include > > When lloking into the xsd-frontend/semantic-graph directory, I can see a file > "fundamental.hxx.m4" only. There are other header files without the m4 > postfix, > so I assume something went wrong while building xsd-frontend. Can someone > point > out what that is? > > Thanks > Christian