From travelwitek at gmail.com  Mon Feb  7 04:59:32 2011
From: travelwitek at gmail.com (Witek Piet)
Date: Mon Feb  7 04:59:41 2011
Subject: [xsde-users] XSD/e and xsi:nil support?
Message-ID: <AANLkTi=QRcmBrnn7noxT-LV-Nv0A=1MJg2diKm4RDHbk@mail.gmail.com>

Hi,

I have read in the XSD support list, that XSD does not support nillable and
xsi:nil. Based on my tests I assume that this (nillable and xsi:nil) is not
supported by XSD/e either. Could you please confirm if this option is
supported by XSD/e? If not are there any plans on implementing this feature
in future releases of XSD and XSD/e?

Does XSD and XSD/e support any other mechanism for assigning a null value to
an element? If this is the case could you please give me a hint?

Your help is highly appreciated! ;-)

Thanks in Advance,
Witek
From boris at codesynthesis.com  Mon Feb  7 12:30:07 2011
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Mon Feb  7 12:13:25 2011
Subject: [xsde-users] XSD/e and xsi:nil support?
In-Reply-To: <AANLkTi=QRcmBrnn7noxT-LV-Nv0A=1MJg2diKm4RDHbk@mail.gmail.com>
References: <AANLkTi=QRcmBrnn7noxT-LV-Nv0A=1MJg2diKm4RDHbk@mail.gmail.com>
Message-ID: <boris.20110207191318@codesynthesis.com>

Hi Witek,

Witek Piet <travelwitek@gmail.com> writes:

> I have read in the XSD support list, that XSD does not support nillable and
> xsi:nil. Based on my tests I assume that this (nillable and xsi:nil) is not
> supported by XSD/e either.

That's correct.


> If not are there any plans on implementing this feature in future releases
> of XSD and XSD/e?

No, not at the moment. This is one of those XML Schema "mis-features" that
doesn't make much sense, doesn't map cleanly to object-oriented models, and,
as a result, hardly used by anybody.

The main problem with the nillable elements in XML Schema is the fact that
an element declared nil can still have a full set of attributes. Consider,
for example:

  <complexType name="person">
    <sequence>
      <element name="first-name" type="string"/>
      <element name="last-name" type="string"/>
    </sequence>
    <element name="id" type="unsignedLong"/>
    <element name="email" type="string"/>
  </complexType>

  <element name="person" type="person" nillable="true"/>

Then in your XML document you can have:

  <person xsi:nil="true"/>

Which makes sense. But then you can also have this:

  <person xsi:nil="true" id="123" email="null@null.com"/>

Which doesn't make much sense. In a sense, this means that only half of the
object is NULL. There is no way in programming languages such as C++ to have
pointer or object that is "half NULL".


> Does XSD and XSD/e support any other mechanism for assigning a null 
> value to an element? If this is the case could you please give me a 
> hint?

The cleanest and most straightforward way is simply to declare an element
optional by setting its minOccurs="0". For example:

  <complexType name="bank_account">
    <sequence>
      <element name="primary_holder" type="person"/>
      <element name="secondary_holder" type="person" minOccurs="0"/>
    </sequence>
  </complexType>

Here we have a bank account type which must have a primary account holder.
It also may or may not have the secondary holder. For example:

  <bank_account>
    <primary_holder/>
      ...
    </primary_holder>
  </bank_account>

  <bank_account>
    <primary_holder/>
      ...
    </primary_holder>

    <secondary_holder/>
      ...
    </secondary_holder>
  </bank_account>

In the C++/Hybrid object mode you will check whether secondary holder
is set like this:

bank_account& acc = ...

if (acc.secondary_holder_present ())
{
  person& sh (acc.secondary_holder ());
  ...
}

Which, in a way, is similar to checking whether a pointer is NULL.

Boris

From travelwitek at gmail.com  Tue Feb  8 03:20:28 2011
From: travelwitek at gmail.com (Witek Piet)
Date: Tue Feb  8 03:20:39 2011
Subject: [xsde-users] XSD/e and xsi:nil support?
In-Reply-To: <boris.20110207191318@codesynthesis.com>
References: <AANLkTi=QRcmBrnn7noxT-LV-Nv0A=1MJg2diKm4RDHbk@mail.gmail.com>
	<boris.20110207191318@codesynthesis.com>
Message-ID: <AANLkTimydmbm0H=hK1ojVpdBE9MH4DD3iEVQBH5u=n5v@mail.gmail.com>

Hi Boris,

Thank you very much for your quick answer. It sounds as if nillable elements
is not the approach to follow ... . ;-)

Basically we want to define in XSD a config data struture, e.g.:
<complexType name="config">
  <sequence>
    <element name="sampling_enable" type="boolean" minOccurs="0"></element>
    <element name="sampling_rate" type="unsignedShort"
minOccurs="0"</element>
    ...
  </sequence>
</complexType>

<element name="config" type="config"/>

We want to be able to set/get elements of this data structure using the tags
of the complexType-definition. We have defined three primitives:
 *) set: client -> data manager: set an element
 *) get: client -> data manager: get an element
 *) response: data manager -> client: answer to get

'set', 'get' and 'response' would look like this (I have left out the
XSD-definition for these):
<set>
  <config>
    <sampling_enable>true</sampling_enable>
  </config>
</set>

<get>
  <config>
    <sampling_enable></sampling_enable>
  </config>
</get>

<response>
  <config>
    <sampling_enable>true</sampling_enable>
  </config>
</get>

'set' and 'response' would work fine using the definition of config, but
'get' would not work as it does not contain a value. We would rather avoid
sending a 'dummy' value in 'get'. As I see it the only solution to this, if
nillable is not possible, is to define an enum (or similar) describing the
elements of config. This would be used in 'get' to specify which elements of
config are requested. Do you agree on that?

Once again, thank you very much for your help.

Best regards,
Witek


On Mon, Feb 7, 2011 at 6:30 PM, Boris Kolpackov <boris@codesynthesis.com>wrote:

> Hi Witek,
>
> Witek Piet <travelwitek@gmail.com> writes:
>
> > I have read in the XSD support list, that XSD does not support nillable
> and
> > xsi:nil. Based on my tests I assume that this (nillable and xsi:nil) is
> not
> > supported by XSD/e either.
>
> That's correct.
>
>
> > If not are there any plans on implementing this feature in future
> releases
> > of XSD and XSD/e?
>
> No, not at the moment. This is one of those XML Schema "mis-features" that
> doesn't make much sense, doesn't map cleanly to object-oriented models,
> and,
> as a result, hardly used by anybody.
>
> The main problem with the nillable elements in XML Schema is the fact that
> an element declared nil can still have a full set of attributes. Consider,
> for example:
>
>  <complexType name="person">
>    <sequence>
>      <element name="first-name" type="string"/>
>      <element name="last-name" type="string"/>
>    </sequence>
>    <element name="id" type="unsignedLong"/>
>    <element name="email" type="string"/>
>  </complexType>
>
>  <element name="person" type="person" nillable="true"/>
>
> Then in your XML document you can have:
>
>  <person xsi:nil="true"/>
>
> Which makes sense. But then you can also have this:
>
>  <person xsi:nil="true" id="123" email="null@null.com"/>
>
> Which doesn't make much sense. In a sense, this means that only half of the
> object is NULL. There is no way in programming languages such as C++ to
> have
> pointer or object that is "half NULL".
>
>
> > Does XSD and XSD/e support any other mechanism for assigning a null
> > value to an element? If this is the case could you please give me a
> > hint?
>
> The cleanest and most straightforward way is simply to declare an element
> optional by setting its minOccurs="0". For example:
>
>  <complexType name="bank_account">
>    <sequence>
>      <element name="primary_holder" type="person"/>
>      <element name="secondary_holder" type="person" minOccurs="0"/>
>    </sequence>
>  </complexType>
>
> Here we have a bank account type which must have a primary account holder.
> It also may or may not have the secondary holder. For example:
>
>  <bank_account>
>    <primary_holder/>
>      ...
>    </primary_holder>
>  </bank_account>
>
>  <bank_account>
>    <primary_holder/>
>      ...
>    </primary_holder>
>
>    <secondary_holder/>
>      ...
>    </secondary_holder>
>  </bank_account>
>
> In the C++/Hybrid object mode you will check whether secondary holder
> is set like this:
>
> bank_account& acc = ...
>
> if (acc.secondary_holder_present ())
> {
>  person& sh (acc.secondary_holder ());
>  ...
> }
>
> Which, in a way, is similar to checking whether a pointer is NULL.
>
> Boris
>
From boris at codesynthesis.com  Tue Feb  8 12:41:25 2011
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Tue Feb  8 12:24:32 2011
Subject: [xsde-users] XSD/e and xsi:nil support?
In-Reply-To: <AANLkTimydmbm0H=hK1ojVpdBE9MH4DD3iEVQBH5u=n5v@mail.gmail.com>
References: <AANLkTi=QRcmBrnn7noxT-LV-Nv0A=1MJg2diKm4RDHbk@mail.gmail.com>
	<boris.20110207191318@codesynthesis.com>
	<AANLkTimydmbm0H=hK1ojVpdBE9MH4DD3iEVQBH5u=n5v@mail.gmail.com>
Message-ID: <boris.20110208193232@codesynthesis.com>

Hi Witek,

Witek Piet <travelwitek@gmail.com> writes:

> <set>
>   <config>
>     <sampling_enable>true</sampling_enable>
>   </config>
> </set>
> 
> <get>
>   <config>
>     <sampling_enable></sampling_enable>
>   </config>
> </get>
> 
> <response>
>   <config>
>     <sampling_enable>true</sampling_enable>
>   </config>
> </get>
> 
> 'set' and 'response' would work fine using the definition of config, but
> 'get' would not work as it does not contain a value. We would rather avoid
> sending a 'dummy' value in 'get'. As I see it the only solution to this, if
> nillable is not possible, is to define an enum (or similar) describing the
> elements of config. This would be used in 'get' to specify which elements of
> config are requested. Do you agree on that?

Yes, I think this is a good idea. I would do something like this:

  <simpleType name="config_element">
    <restriction base="string">
      <enumeration value="sampling_enable"/>
      <enumeration value="sampling_rate"/>
    </restriction>
  </simpleType>

  <simpleType name="config_list">
    <list itemType="config_element"/>
  </simpleType>

  <complexType name="get">
    <sequence>
      <element name="config" type="config_list"/>
    </sequence>
  </complexType>

Then, your get request would look like this:

<get>
  <config>sampling_enable</config>
</get>

Or:

<get>
  <config>sampling_enable sampling_rate</config>
</get>

Boris

From travelwitek at gmail.com  Wed Feb  9 07:40:26 2011
From: travelwitek at gmail.com (Witek Piet)
Date: Wed Feb  9 07:40:36 2011
Subject: [xsde-users] XSD/e and xsi:nil support?
In-Reply-To: <boris.20110208193232@codesynthesis.com>
References: <AANLkTi=QRcmBrnn7noxT-LV-Nv0A=1MJg2diKm4RDHbk@mail.gmail.com>
	<boris.20110207191318@codesynthesis.com>
	<AANLkTimydmbm0H=hK1ojVpdBE9MH4DD3iEVQBH5u=n5v@mail.gmail.com>
	<boris.20110208193232@codesynthesis.com>
Message-ID: <AANLkTikugaMS1ukw=8sKqsA8Couhmzt+Ftkj-31LNY95@mail.gmail.com>

Once again thanks for answering! ;-) The only thing that bothers me about
this approach is its maintainability, i.e. the enum has to be kept in sync
with the data structure.

Best regards,
Witek

On Tue, Feb 8, 2011 at 6:41 PM, Boris Kolpackov <boris@codesynthesis.com>wrote:

> Hi Witek,
>
> Witek Piet <travelwitek@gmail.com> writes:
>
> > <set>
> >   <config>
> >     <sampling_enable>true</sampling_enable>
> >   </config>
> > </set>
> >
> > <get>
> >   <config>
> >     <sampling_enable></sampling_enable>
> >   </config>
> > </get>
> >
> > <response>
> >   <config>
> >     <sampling_enable>true</sampling_enable>
> >   </config>
> > </get>
> >
> > 'set' and 'response' would work fine using the definition of config, but
> > 'get' would not work as it does not contain a value. We would rather
> avoid
> > sending a 'dummy' value in 'get'. As I see it the only solution to this,
> if
> > nillable is not possible, is to define an enum (or similar) describing
> the
> > elements of config. This would be used in 'get' to specify which elements
> of
> > config are requested. Do you agree on that?
>
> Yes, I think this is a good idea. I would do something like this:
>
>  <simpleType name="config_element">
>    <restriction base="string">
>      <enumeration value="sampling_enable"/>
>      <enumeration value="sampling_rate"/>
>    </restriction>
>  </simpleType>
>
>  <simpleType name="config_list">
>    <list itemType="config_element"/>
>  </simpleType>
>
>  <complexType name="get">
>    <sequence>
>      <element name="config" type="config_list"/>
>    </sequence>
>  </complexType>
>
> Then, your get request would look like this:
>
> <get>
>  <config>sampling_enable</config>
> </get>
>
> Or:
>
> <get>
>  <config>sampling_enable sampling_rate</config>
> </get>
>
> Boris
>
From boris at codesynthesis.com  Wed Feb  9 11:10:42 2011
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Wed Feb  9 10:53:37 2011
Subject: [xsde-users] XSD/e and xsi:nil support?
In-Reply-To: <AANLkTikugaMS1ukw=8sKqsA8Couhmzt+Ftkj-31LNY95@mail.gmail.com>
References: <AANLkTi=QRcmBrnn7noxT-LV-Nv0A=1MJg2diKm4RDHbk@mail.gmail.com>
	<boris.20110207191318@codesynthesis.com>
	<AANLkTimydmbm0H=hK1ojVpdBE9MH4DD3iEVQBH5u=n5v@mail.gmail.com>
	<boris.20110208193232@codesynthesis.com>
	<AANLkTikugaMS1ukw=8sKqsA8Couhmzt+Ftkj-31LNY95@mail.gmail.com>
Message-ID: <boris.20110209180705@codesynthesis.com>

Hi Witek,

Witek Piet <travelwitek@gmail.com> writes:

> The only thing that bothers me about this approach is its maintainability,
> i.e. the enum has to be kept in sync with the data structure.

Yes, that's the drawback of this approach. The alternative would be to
do something like this (using optional elements/attributes):

<set>
  <config>
    <sampling_enable><value>true</value></sampling_enable>
  </config>
</set>

<get>
  <config>
    <sampling_enable/>
  </config>
</get>

Or, if your values are of simple types, you can do:

<set>
  <config>
    <sampling_enable value="true"/>
  </config>
</set>

Boris

From annulen at yandex.ru  Wed Feb  9 14:58:04 2011
From: annulen at yandex.ru (Konstantin Tokarev)
Date: Wed Feb  9 14:58:13 2011
Subject: [xsde-users] XSD/e non-validating parsers and invalid XML input
Message-ID: <54211297281485@web110.yandex.ru>

Hi all,

I'd like to use XSD/e parser generator with --suppress-validation flag to produce fast non-validating parsers.

Can generated code be considered as safe from segfaults in case input XML is not valid?
If it is not well-formed?

-- 
Regards,
Konstantin

From boris at codesynthesis.com  Thu Feb 10 05:39:03 2011
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Thu Feb 10 05:22:14 2011
Subject: [xsde-users] XSD/e non-validating parsers and invalid XML input
In-Reply-To: <54211297281485@web110.yandex.ru>
References: <54211297281485@web110.yandex.ru>
Message-ID: <boris.20110210122734@codesynthesis.com>

Hi Konstantin,

Konstantin Tokarev <annulen@yandex.ru> writes:

> I'd like to use XSD/e parser generator with --suppress-validation flag
> to produce fast non-validating parsers.
> 
> Can generated code be considered as safe from segfaults in case input 
> XML is not valid?

The generated code is safe but you probably won't be able to write your
application in a way that we will be safe. Just to give you an example,
consider a required element of a variable-length type. If the XML being
parsed misses this element, the object model will have a NULL pointer for
this element. But there is no easy way (API-wise) for you to determine
that this value is missing. You could generate detach functions (see the
--generate-detach option, only available in 3.2.0) and first detach
such an element to see if the returned pointer is NULL.

> If it is not well-formed?

If the document is not well-formed, you will get a parsing error. There
is no way to disable well-formedness checking.

Boris

From annulen at yandex.ru  Thu Feb 10 06:31:41 2011
From: annulen at yandex.ru (Konstantin Tokarev)
Date: Thu Feb 10 06:31:51 2011
Subject: [xsde-users] XSD/e non-validating parsers and invalid XML input
In-Reply-To: <boris.20110210122734@codesynthesis.com>
References: <54211297281485@web110.yandex.ru>
	<boris.20110210122734@codesynthesis.com>
Message-ID: <318461297337502@web21.yandex.ru>

Hi Boris,

> The generated code is safe but you probably won't be able to write your
> application in a way that we will be safe. Just to give you an example,
> consider a required element of a variable-length type. If the XML being
> parsed misses this element, the object model will have a NULL pointer for
> this element. But there is no easy way (API-wise) for you to determine
> that this value is missing. 

Is there a chance it will be possible in some future version?

>
>> ?If it is not well-formed?
>
> If the document is not well-formed, you will get a parsing error. There
> is no way to disable well-formedness checking.

For example, if document is unfinished (some information loast at the end so there
are unclosed opening tags), will it be possible to parse available data?

-- 
Regards,
Konstantin

From boris at codesynthesis.com  Thu Feb 10 09:50:24 2011
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Thu Feb 10 09:33:36 2011
Subject: [xsde-users] XSD/e non-validating parsers and invalid XML input
In-Reply-To: <318461297337502@web21.yandex.ru>
References: <54211297281485@web110.yandex.ru>
	<boris.20110210122734@codesynthesis.com>
	<318461297337502@web21.yandex.ru>
Message-ID: <boris.20110210164259@codesynthesis.com>

Hi Konstantin,

Konstantin Tokarev <annulen@yandex.ru> writes:

> > The generated code is safe but you probably won't be able to write your
> > application in a way that we will be safe. Just to give you an example,
> > consider a required element of a variable-length type. If the XML being
> > parsed misses this element, the object model will have a NULL pointer for
> > this element. But there is no easy way (API-wise) for you to determine
> > that this value is missing. 
> 
> Is there a chance it will be possible in some future version?

Unlikely. Trying to transform an invalid document to something usable
is an open-ended problem. Even if we were to try and support something
like this, it will complicate the API and result in slower and larger
generated code, which will be a significant drawback for the majority
of applications.


> For example, if document is unfinished (some information loast at the end so there
> are unclosed opening tags), will it be possible to parse available data?

You can do something like this with a partially event-driven, partially in-
memory processing. See the 'streaming' example as well as Section 4.8, 
"Customizing the Object Model" and Section 6.1, "Customizing Parsers and
Serializers" in the Embedded C++/Hybrid Mapping Getting Started Guide.

Boris

From boris at codesynthesis.com  Tue Feb 15 05:55:54 2011
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Tue Feb 15 05:40:23 2011
Subject: [xsde-users] XSD/e 3.2.0 released
Message-ID: <boris.20110215122214@codesynthesis.com>

Hi,

After extensive beta-testing we are pleased to announce the release of 
XSD/e 3.2.0. We would like to thank everyone who tested the alpha and
beta snapshots for this release.

The NEWS file entries for XSD/e 3.2.0 are as follows:

  * Support for ISO-8859-1 in addition to UTF-8 as application encoding.
    Note that this encoding is not the same as the XML document encoding 
    that is being parsed or serialized. Rather, it is the encoding that 
    is used inside the application. When an XML document is parsed, the
    character data is automatically converted to the application encoding.
    Similarly, when an XML document is serialized, the data in the
    application encoding is automatically converted to the resulting
    document encoding. To select a particular encoding, configure the 
    XSD/e runtime library accordingly and pass the --char-encoding option
    to the XSD/e compiler when translating your schemas.

  * Support for custom allocators. This feature allows you to configure
    the XSD/e runtime and generated code to perform memory management
    using custom allocator functions provided by your application instead
    of the standard operator new/delete. For more information, see Section
    3.8, "Custom Allocators" in the C++/Hybrid Mapping Getting Started
    Guide (equivalent documentation is provided for other mappings) as
    well as the 'allocator' example in the examples/cxx/hybrid/ directory.

  * When built with Xerces-C++ 3-series, enable handling of multiple imports
    for the same namespace. Before, all subsequent imports for a namespace
    were ignored which caused errors in some schemas.

  * Automatic mapping for the urn-style XML namespaces. The last component
    in the urn name is used to derive the C++ namespace name.

  * New option, --schema-file-regex, in combination with the existing
    --type-file-regex, can be used to place the generated files into 
    subdirectories or to resolve file name conflicts in the file-per-
    type mode (--file-per-type).

  * Strings used to match regular expression supplied with the
    --namespace-regex and --anonymous-regex options now include the file 
    component for the schema being compiled.

 C++/Hybrid

  * String-based types that use XML Schema restriction by enumeration are 
    now mapped to C++ classes with semantics similar to C++ enum. You can 
    suppress this new mapping and instead get the old behavior (plain 
    inheritance) by specifying the --suppress-enum compiler option. See
    Section 4.3, "Enumerations" in the Getting Started Guide for more
    information.

  * New option, --generate-clone, triggers the generation of clone functions
    for variable-length types. These functions allow you to make dynamically-
    allocated copies of variable-length objects.

  * Support for schema evolution using substitution groups. The 'ignore' and
    'passthrough' examples in the examples/cxx/hybrid/evolution/ directory
    show how the new mechanism works. The 'ignore' example shows how to
    ignore unknown elements. The 'passthrough' example shows how to pass
    the unknown content through parsing and serialization so that the output
    XML contains all the unknown elements.

  * The anySimpleType build-in type is now mapped to std::string or a C-string,
    depending on whether STL is enabled or not.

  * New mapping for anyType with support for polymorphism. For more
    information, see Section 5.14, "Mapping for anyType" in the Embedded
    C++/Hybrid Mapping Getting Started Guide.

  * The object model interface for optional members of variable-length
    types now omits the _present modifier function. This is done to help
    detect programming errors that result from a type becoming variable-
    length due to schema changes. To reset such optional members you can
    call the member modifier function with NULL as its argument.

  * New configuration parameter, XSDE_STL_ITERATOR, makes iterators
    provided by the mapping conform to the STL requirements. This feature
    requires working <iterator> header and allows you to use the standard
    algorithms such as find_if, etc.

  * When the code is generated with the --generate-polymorphic or
    --runtime-polymorphic option, the resulting parser and serializer
    aggregate classes provide the static polymorphic() function which 
    returns true if the object model corresponding to the root element 
    or root type is polymorphic and false otherwise. This can be used 
    together with the XSDE_POLYMORPHIC macro to implement generic parsing
    and serialization code that works with both polymorphic and non-
    polymorphic object models.

  * XML Schema union types with members that are enumeration types are 
    automatically converted to equivalent enumeration types with a union 
    of all the member's enumerators.

 C++/Parser

  * Support for the following XML Schema facets:

    String-based types:
      - length
      - minLength
      - maxLength
      - pattern
      - whiteSpace
      - enumeration

    Integer and floating-point types:
      - minExclusive
      - minInclusive
      - maxExclusive
      - maxInclusive

    For more information on the pattern facet validation, see the XSDE_REGEXP
    parameter in the configuration files.

  * The anySimpleType build-in type is now mapped to std::string or a C-string,
    depending on whether STL is enabled or not.

 C++/Serializer

  * Support for the following XML Schema facets:

    String-based types:
      - length
      - minLength
      - maxLength
      - pattern
      - enumeration

    Integer and floating-point types:
      - minExclusive
      - minInclusive
      - maxExclusive
      - maxInclusive

    For more information on the pattern facet validation, see the XSDE_REGEXP
    parameter in the configuration files.

  * The anySimpleType build-in type is now mapped to std::string or a C-string,
    depending on whether STL is enabled or not.


This release adds official support, instructions, and sample configuration
files for the following platforms/toolchains:

Android/Android NDK
Symbian/CSL-GCC (GCCE)
Integrity 178b/Green Hills MULTI C/C++

It is now also possible to build the XSD/e runtime library for iPhoneOS/iOS
with the XCode project.

Precompiled binary distributions are available from the product's download
page:

  http://www.codesynthesis.com/products/xsde/download.xhtml

Source code for this release is available from the project's web page:

  http://www.codesynthesis.com/projects/xsde/

SHA1 checksums for this release:

a9cbe6cce22001507f4a333f2bb9342df3b4cf64  xsde-3.2.0.tar.bz2
bde4b440069811e19cf8aa76b8dd758c0a8bf50a  xsde-3.2.0+dep.tar.bz2
c26f265fc62e65d07a620c7b70d288c0cfd43612  xsde-3.2.0-i686-linux-gnu.tar.bz2
2d59565013fe4436319ee8bd2bf324477c6fc8d7  xsde-3.2.0-x86_64-linux-gnu.tar.bz2
cb1123dd72048d2c3ed5cf647584fa40763ea687  xsde-3.2.0-i686-macosx.tar.bz2
1bcd1572f2daee23a46b056efc8edde2dd349238  xsde-3.2.0-sparc-solaris.tar.gz
0ec3257498a9f79aafe960a1bc1394ffaac920e9  xsde-3.2.0-i686-solaris.tar.gz
06ae08d68b413fe143e686c7cb488030a98332ff  xsde-3.2.0-i686-windows.zip

Enjoy,
	Boris

From ivan.lelann at free.fr  Tue Feb 15 07:02:03 2011
From: ivan.lelann at free.fr (Ivan Le Lann)
Date: Tue Feb 15 07:02:13 2011
Subject: [xsde-users] XSD/e 3.2.0 released
In-Reply-To: <410311874.326871297771243467.JavaMail.root@zimbra36-e6.priv.proxad.net>
Message-ID: <1627330974.327051297771323798.JavaMail.root@zimbra36-e6.priv.proxad.net>


----- "Boris Kolpackov" <boris@codesynthesis.com> a ?crit :

> Hi,
> 
> After extensive beta-testing we are pleased to announce the release of
> 
> XSD/e 3.2.0.

Congratulations!

> The NEWS file entries for XSD/e 3.2.0 are as follows:
> 

(snip impressive list of new features)

> 
>   * Support for schema evolution using substitution groups. The
> 'ignore' and
>     'passthrough' examples in the examples/cxx/hybrid/evolution/
> directory
>     show how the new mechanism works. The 'ignore' example shows how
> to
>     ignore unknown elements. The 'passthrough' example shows how to
> pass
>     the unknown content through parsing and serialization so that the
> output
>     XML contains all the unknown elements.
> 
>   * New mapping for anyType with support for polymorphism.

I missed see anyType in the beta changes. That's great!
Could any_type and 'passthrough' efforts lead to built-in xs:any support 
in future XSD/e Hydrid release ? 

Regards,
Ivan.

From boris at codesynthesis.com  Tue Feb 15 08:49:20 2011
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Tue Feb 15 08:33:52 2011
Subject: [xsde-users] XSD/e 3.2.0 released
In-Reply-To: <1627330974.327051297771323798.JavaMail.root@zimbra36-e6.priv.proxad.net>
References: <410311874.326871297771243467.JavaMail.root@zimbra36-e6.priv.proxad.net>
	<1627330974.327051297771323798.JavaMail.root@zimbra36-e6.priv.proxad.net>
Message-ID: <boris.20110215153831@codesynthesis.com>

Hi Ivan,

Ivan Le Lann <ivan.lelann@free.fr> writes:

> Could any_type and 'passthrough' efforts lead to built-in xs:any support 
> in future XSD/e Hydrid release ?

The problem with storing raw XML in any_type is that it can have the
mixed content structure (interleaved elements and text). It is possible
to implement a simple and cheap DOM-like structure without the support
for mixed content, which is what is done in the passthrough example.
This support will also satisfy 90% of the use-cases. On the other hand,
supporting mixed content complicates things significantly. If we to
provide generic raw XML support in any_type/xs:any, we would have to have
support for mixed content which won't be used by majority of the users
and which will be quite expensive, footprint-wise. So for now we have
decided to by default ignore the content in xs:any/any_type and let
you customize the object model if you need this functionality. Since
in most cases you won't need mixed content support, this should be
fairly easy to do.

Boris

From ivan.lelann at free.fr  Fri Feb 18 17:43:10 2011
From: ivan.lelann at free.fr (Ivan Le Lann)
Date: Fri Feb 18 17:43:19 2011
Subject: [xsde-users] About xs:normalizedString
In-Reply-To: <108539588.1571211298068769065.JavaMail.root@zimbra36-e6.priv.proxad.net>
Message-ID: <67492061.1571371298068990434.JavaMail.root@zimbra36-e6.priv.proxad.net>

Hello,

With XSD/e Hybrid, I recently got the issue of handling 
"dirty" input like this one: <name>[LF]Joe</name>,
where [LF] stands for line feed ascii code (0A).

I thought I could get rid of LF by turning "name" from xs:string 
to xs:normalizedString. Now after parse/serialize the output is :

<name> Joe</name>

Is this new space exspected behavior ?
I quickly tried with xs:token and got the same result.

This was with XSD/e Hybrid 3.2.0 on Windows VS2003.
I did not test any other configuration.

Regards,
Ivan

From ivan.lelann at free.fr  Mon Feb 21 05:05:36 2011
From: ivan.lelann at free.fr (Ivan Le Lann)
Date: Mon Feb 21 05:05:45 2011
Subject: [xsde-users] About xs:normalizedString
In-Reply-To: <1610324667.1695431298282676175.JavaMail.root@zimbra36-e6.priv.proxad.net>
Message-ID: <1106626617.1695551298282736134.JavaMail.root@zimbra36-e6.priv.proxad.net>

Replying to myself,

It seems that:

1) normalizeString is supposed to replace line feed with space :
See http://www.w3.org/TR/xmlschema11-2/#rf-whiteSpace
and http://www.w3.org/TR/xmlschema11-2/#normalizedString

2) among other things, xs:token does the trimming I was looking for.
(My first test for this was flawed)

Sorry for the noise,
Ivan


----- "Ivan Le Lann" <ivan.lelann@free.fr> a ?crit :

> Hello,
> 
> With XSD/e Hybrid, I recently got the issue of handling 
> "dirty" input like this one: <name>[LF]Joe</name>,
> where [LF] stands for line feed ascii code (0A).
> 
> I thought I could get rid of LF by turning "name" from xs:string 
> to xs:normalizedString. Now after parse/serialize the output is :
> 
> <name> Joe</name>
> 
> Is this new space exspected behavior ?
> I quickly tried with xs:token and got the same result.
> 
> This was with XSD/e Hybrid 3.2.0 on Windows VS2003.
> I did not test any other configuration.
> 
> Regards,
> Ivan

From hayim at marvell.com  Sun Feb 27 08:50:56 2011
From: hayim at marvell.com (Haim Boot)
Date: Sun Feb 27 10:54:14 2011
Subject: [xsde-users] XSD/e: Problem in building project which uses XSD/e
Message-ID: <BC373419EB4337418B2B595BAEDC155FCDBB80DC15@IL-MB01.marvell.com>

Hi

I'm using XSD/e version 3.2.0 for generating XSD code for embedded VxWorks system.

In the command shell I executed:
C:\xsde-3.2.0-i686-windows\bin>xsde.exe cxx-parser --no-stl "C:\<some XSD>.xsd".

2 files were generated (cxx & hxx files).
When I try to build my project after including the hxx file (not even the link stage) I get the following errors:

C:/xsde-3.2.0-i686-windows/libxsde/xsde/cxx/buffer.hxx:52: parse error before `&'
C:/xsde-3.2.0-i686-windows/libxsde/xsde/cxx/buffer.hxx:54: syntax error before `&'
C:/xsde-3.2.0-i686-windows/libxsde/xsde/cxx/buffer.hxx:76: invalid use of undefined type `class xsde::cxx::buffer'
C:/xsde-3.2.0-i686-windows/libxsde/xsde/cxx/buffer.hxx:20: forward declaration of `class xsde::cxx::buffer'
C:/xsde-3.2.0-i686-windows/libxsde/xsde/cxx/buffer.hxx:76: parse error before `)'
C:/xsde-3.2.0-i686-windows/libxsde/xsde/cxx/buffer.hxx:78: syntax error before `*'
C:/xsde-3.2.0-i686-windows/libxsde/xsde/cxx/buffer.hxx:86: invalid use of undefined type `class xsde::cxx::buffer'
C:/xsde-3.2.0-i686-windows/libxsde/xsde/cxx/buffer.hxx:20: forward declaration of `class xsde::cxx::buffer'


These errors are located in lines within the declaration of class buffer (which is the class that is not recognized according to the compiler).
I get similar errors in class/struct string when not using --no-stl flag.

Thanks in advance,
Haim

________________________________
Haim Boot, Marvell Israel - SW Engineer
6 Hamada Street
Mordot HaCarmel Industrial Park
Yokneam, 20692, Israel
Email: hayim@marvell.com<mailto:hayim@marvell.com>
Office:  +972.4.9091520 - OnNet: 704.1520
Fax:      +972.4.9091501
Web site: http://www.marvell.com<http://www.marvell.com/>

This message may contain confidential, proprietary or legally privileged information. The information is intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by telephone or by e-mail and delete the message from your computer.
________________________________

From boris at codesynthesis.com  Mon Feb 28 04:19:02 2011
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Mon Feb 28 04:17:36 2011
Subject: [xsde-users] XSD/e: Problem in building project which uses XSD/e
In-Reply-To: <BC373419EB4337418B2B595BAEDC155FCDBB80DC15@IL-MB01.marvell.com>
References: <BC373419EB4337418B2B595BAEDC155FCDBB80DC15@IL-MB01.marvell.com>
Message-ID: <boris.20110228110716@codesynthesis.com>

Hi Haim,

Haim Boot <hayim@marvell.com> writes:

> In the command shell I executed:
> xsde.exe cxx-parser --no-stl "C:\<some XSD>.xsd".

Which version of VxWorks are you using? If it is 5.x, then you will also
need to disable C++ exceptions besides other things (see the etc/vxworks/
directory for sample configuration files).


> When I try to build my project after including the hxx file (not even 
> the link stage) I get the following errors:
> 
> libxsde/xsde/cxx/buffer.hxx:52: parse error before `&'
>
> I get similar errors in class/struct string when not using --no-stl flag.

Hm, this is very strange. The VxWorks toolchain is old but it should still
be able to handle copy constructors. I assume you are using the gcc compiler.
Can you tell me which version it is (gcc --version)?

The only thing that I can think of that could cause this kind of strange
behavior is that you have 'buffer' and 'string' defined as preprocessor
macros. Can you try to include the generated .hxx file first thing in
your C++ source file and see if you still get these errors?

Boris