From aazmp at yandex.ru  Mon Nov 19 10:13:22 2018
From: aazmp at yandex.ru (=?utf-8?B?0J/QtdGB0L7RhtC60LjQuSDQnNCw0LrRgdC40Lw=?=)
Date: Mon Nov 19 10:24:14 2018
Subject: [xsde-users] Absent .pre() and .post() methods in some aggregators
Message-ID: <5703481542640402@myt5-184376c2d7f8.qloud-c.yandex.net>

Greetings!

i'm trying to port project from using XSD cxx-tree to XSD/e cxx-hybrid to reduce memory usage
Sadly without much knowledge of both

Getting started guide suggests, that serialization of root elements is going like this

for 
rs::productMetadata::EarthObservationType eoType;

rs::productMetadataResursBmi::EarthObservation_saggr elem_s;
xml_schema::document_simpl doc_s(elem_s.root_serializer(), elem_s.root_name (), true);
elem_s.pre(eoType);
doc_s.serialize (mystream, xml_schema::document_simpl::pretty_print);
elem_s.post();

but sometimes aggregators do not have .pre() and .post() functions (i.e with this rs::productMetadataResursBmi::EarthObservation_saggr/_paggr)
is this correct situation?

options used with xsde cxx-hybrid --generate-polymorphic --generate-serializer --generate-aggregate --generate-parser



type is defined like this (separated into several different namespaces and .xsd files)
<xs:element name="EarthObservation" type="productMetadata:EarthObservationType" substitutionGroup="opt:EarthObservation">
		<xs:annotation>
			<xs:documentation>Root element for level 0 product description</xs:documentation>
		</xs:annotation>
	</xs:element>

it's line of base type/elements is:
1.
<xs:element name="EarthObservation" type="opt:EarthObservationType" substitutionGroup="eop:EarthObservation">
		<xs:annotation>
			<xs:documentation>eop root element for Optical Earth Observation Product description</xs:documentation>
		</xs:annotation>
	</xs:element>

2. 
<xs:element name="EarthObservation" type="eop:EarthObservationType" substitutionGroup="gml:Observation">
		<xs:annotation>
			<xs:documentation>eop root element for generic Earth Observation Product description</xs:documentation>
		</xs:annotation>
	</xs:element>

3. 
<element name="Observation" type="gml:ObservationType" substitutionGroup="gml:_Feature"/>
	<!-- ================================================= -->
	<complexType name="ObservationType">
		<complexContent>
			<extension base="gml:AbstractFeatureType">
				<sequence>
					<element ref="gml:validTime" minOccurs="0"/>
					<element ref="gml:using" minOccurs="0"/>
					<element ref="gml:target" minOccurs="0"/>
					<element ref="gml:resultOf" minOccurs="0"/>
				</sequence>
			</extension>
		</complexContent>
	</complexType>

4. 
<complexType name="AbstractFeatureType" abstract="true">
		<annotation>
			<documentation>An abstract feature provides a set of common properties, including id, metaDataProperty, name and description inherited from AbstractGMLType, plus boundedBy.    A concrete feature type must derive from this type and specify additional  properties in an application schema. A feature must possess an identifying attribute ('id' - 'fid' has been deprecated).</documentation>
		</annotation>
		<complexContent>
			<extension base="gml:AbstractGMLType">
				<sequence>
					<element ref="gml:boundedBy" minOccurs="0"/>
					<element ref="gml:location" minOccurs="0">
						<annotation>
							<appinfo>deprecated</appinfo>
							<documentation>deprecated in GML version 3.1</documentation>
						</annotation>
					</element>
					<!-- additional properties must be specified in an application schema -->
				</sequence>
			</extension>
		</complexContent>
	</complexType>

5.
<complexType name="AbstractGMLType" abstract="true">
		<annotation>
			<documentation>All complexContent GML elements are directly or indirectly derived from this abstract supertype 
	to establish a hierarchy of GML types that may be distinguished from other XML types by their ancestry. 
	Elements in this hierarchy may have an ID and are thus referenceable.</documentation>
		</annotation>
		<sequence>
			<group ref="gml:StandardObjectProperties"/>
		</sequence>
		<attribute ref="gml:id" use="optional"/>
	</complexType>

Tried also to generate all schemes in single call with with root-element-all
also defined these types polyporphic



Thanks!

Maxim

From boris at codesynthesis.com  Tue Nov 20 07:14:13 2018
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Tue Nov 20 07:24:58 2018
Subject: [xsde-users] Absent .pre() and .post() methods in some aggregators
In-Reply-To: <5703481542640402@myt5-184376c2d7f8.qloud-c.yandex.net>
References: <5703481542640402@myt5-184376c2d7f8.qloud-c.yandex.net>
Message-ID: <boris.20181120141209@codesynthesis.com>

???????? ?????? <aazmp@yandex.ru> writes:

> but sometimes aggregators do not have .pre() and .post() functions
> (i.e with this rs::productMetadataResursBmi::EarthObservation_saggr/_paggr)
> is this correct situation?

Check the class definitions for such aggregates, my guess is they are empty
or some such.

From aazmp at yandex.ru  Tue Nov 20 08:57:18 2018
From: aazmp at yandex.ru (=?utf-8?B?0J/QtdGB0L7RhtC60LjQuSDQnNCw0LrRgdC40Lw=?=)
Date: Tue Nov 20 09:08:11 2018
Subject: [xsde-users] Absent .pre() and .post() methods in some aggregators
In-Reply-To: <boris.20181120141209@codesynthesis.com>
References: <5703481542640402@myt5-184376c2d7f8.qloud-c.yandex.net>
	<boris.20181120141209@codesynthesis.com>
Message-ID: <11665411542722238@sas2-7b909973f402.qloud-c.yandex.net>

in case of serializer it has a lot of "_simpl" in "public:"


::xml_schema::any_type_simpl any_type_s_;
::gml::SurfacePropertyType_simpl SurfacePropertyType_s_;
...

including root

::rs::productMetadata::EarthObservationType_simpl&
      root_serializer ()
      {
        return this->EarthObservationType_s_;
      }

when i switch from
elem_s.pre(eoType);
to
elem_s.root_serializer().pre(eoType);

i get an assert
assert (this->EarthObservationType_impl_); (when serializing attributes of one of the base classes)



20.11.2018, 15:14, "Boris Kolpackov" <boris@codesynthesis.com>:
>
> Check the class definitions for such aggregates, my guess is they are empty
> or some such.

From boris at codesynthesis.com  Thu Nov 22 11:26:18 2018
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Thu Nov 22 11:37:09 2018
Subject: [xsde-users] Absent .pre() and .post() methods in some aggregators
In-Reply-To: <11665411542722238@sas2-7b909973f402.qloud-c.yandex.net>
References: <5703481542640402@myt5-184376c2d7f8.qloud-c.yandex.net>
	<boris.20181120141209@codesynthesis.com>
	<11665411542722238@sas2-7b909973f402.qloud-c.yandex.net>
Message-ID: <boris.20181122182200@codesynthesis.com>

???????? ?????? <aazmp@yandex.ru> writes:

> elem_s.pre(eoType);
> to
> elem_s.root_serializer().pre(eoType);

The pre()/post() functions are not generated for polymorphic
type/element aggregates (because we don't know which of the
serializers will be used). Check the 'polyroot' example -- it
deals with exactly this situation.

From joost.boogaard at philips.com  Thu Nov 29 04:00:52 2018
From: joost.boogaard at philips.com (Boogaard, Joost)
Date: Thu Nov 29 05:25:06 2018
Subject: [xsde-users] XSDE: Is more error information from generated code
	possible?
Message-ID: <VI1P122MB001512D0A74F08E5EDA0A7A692D20@VI1P122MB0015.EURP122.PROD.OUTLOOK.COM>

Dear reader,


We use XSDE (version 3.3.0.a8)  to serialize C++ classes to xml

When serializing a class named ComputationResults we sometimes encounter the following error:


N4sgse17xsdegeneratedcode3xml18ComputationResultsE: schema error: expected element not encountered


This is most likely an error in our code that fills the xml model

However, the class is large and the model adapter is complicated

The error message does not provide much details about the error

e.g. what element was expected?


Is there a way to get more detailed error information from generated code by XSDE?


Kind regards,

Joost Boogaard


Software engineer

Digital & Computational Pathology

Philips Nederland B.V.

Veenpluis 4-6

5684 PC Best

the Netherlands


________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.
From boris at codesynthesis.com  Thu Nov 29 07:43:42 2018
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Thu Nov 29 07:54:54 2018
Subject: [xsde-users] XSDE: Is more error information from generated code
	possible?
In-Reply-To: <VI1P122MB001512D0A74F08E5EDA0A7A692D20@VI1P122MB0015.EURP122.PROD.OUTLOOK.COM>
References: <VI1P122MB001512D0A74F08E5EDA0A7A692D20@VI1P122MB0015.EURP122.PROD.OUTLOOK.COM>
Message-ID: <boris.20181129142934@codesynthesis.com>

Boogaard, Joost <joost.boogaard@philips.com> writes:

> When serializing a class named ComputationResults we sometimes
> encounter the following error:
> 
> N4sgse17xsdegeneratedcode3xml18ComputationResultsE: schema error:
> expected element not encountered
> 
> Is there a way to get more detailed error information from generated
> code by XSDE?

Unfortunately not. In this particular case, the content model can
be complex with multiple possible elements (think of a required
xs:choice). Providing this information would be expensive both in
terms of implementation complexity as well as code bloat.

One (admittedly somewhat roundabout) way to help with this would
be to disable schema validation in the generated code, serialize
the (invalid) XML, and then re-parse it with a general-purpose
validating XML parser (e.g., Xerces-C++).