From raulh39 at tid.es  Mon Sep  4 07:25:33 2006
From: raulh39 at tid.es (Raul Huertas)
Date: Sun Oct 11 15:33:48 2009
Subject: [xsd-users] Handling XML data of unknown type
Message-ID: <44FC0D2D.4040009@tid.es>


   Hi all,
   We are using version 2.7.0 of Xerces and version 2.2.0 of XSD and have
   noted that in the file
       xsd/cxx/xml/dom/elements.txx
   it is used the Xerces function
      DOMNode::getLocalName()
   For example, the line 25 reads:
        name_ (transcode<C> (e->getLocalName ())),
   with "e" being a xercesc::DOMElement wich derives from
   xercesc::DOMNode.
   The problem is that getLocalName() can return NULL. In fact, the
   Xerces documentation says:
   --------------
   virtual const XMLCh* DOMNode::getLocalName ( ) const [pure virtual]
   Returns the local part of the qualified name of this node.
   For nodes created with a DOM Level 1 method, such as createElement
   from the DOMDocument interface, it is null.
   Since:
    DOM Level 2
   --------------
   We are trying to use the second approach to handle XML data of an
   unknown type described in the XSD Wiki
   ([1]http://wiki.codesynthesis.com/Tree/FAQ), but it keeps failing in
   the validation code, throwing an exception:
       "unexpected element encountered"
   This are the relevant lines in our code:
       XercesDOMParser *parser = new XercesDOMParser; //Create the
   parser.
       parser->parse("peticion.xml");                 //Parse the file.
       DOMDocument * dom = parser->getDocument();     //Get the DOM
   document.

       DOMElement* rootElem = dom->getDocumentElement(); //Take rootElem
   to test which XML have the file
       // In this point rootElem->getTagName() returns a valid value:
   "Peticion", but
       // rootElem->getLocalName() returns NULL, so the next line...

       auto_ptr<EstadoSincronismoRequest> unaPeticion(Peticion(*dom));
       // ...throws the exception.
   (
   Our xsd have:
   <xsd:element name="Peticion" type="EstadoSincronismoRequest"/>
   )
   We think that it is not correct to use getLocalName(), but you have to
   use getTagName() or getNodeName(). Is it true?
   By the way, we have discovered that adding this line just before
   calling the parse method:
       parser->setDoNamespaces(true);
   makes the code work. !!
   Is this correct?
   (If this is correct, then I think that it should be pointed in he
   Wiki, shouldn't it?)
   Thanks.

References

   1. http://wiki.codesynthesis.com/Tree/FAQ

From boris at codesynthesis.com  Mon Sep  4 08:16:29 2006
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:48 2009
Subject: [xsd-users] Handling XML data of unknown type
In-Reply-To: <44FC0D2D.4040009@tid.es>
References: <44FC0D2D.4040009@tid.es>
Message-ID: <20060904121629.GB8877@karelia>

Hi Raul,

Raul Huertas <raulh39@tid.es> writes:

>    We are using version 2.7.0 of Xerces and version 2.2.0 of XSD and have
>    noted that in the file
>        xsd/cxx/xml/dom/elements.txx
>    it is used the Xerces function
>       DOMNode::getLocalName()
>    For example, the line 25 reads:
>         name_ (transcode<C> (e->getLocalName ())),
>    with "e" being a xercesc::DOMElement wich derives from
>    xercesc::DOMNode.
>    The problem is that getLocalName() can return NULL.

Apparently it happens when one creates a namespace-unaware DOM
document. By default XSD always turns namespace support on so
it was never a problem. It also does not seem to be too hard to
make it work for the other case. I've patched the elements.txx
file to first try to use getLocalName and if it returns 0 then
use getTagName for elements and getName for attributes. The
patched version of elements.txx is available here:

http://www.codesynthesis.com/~boris/tmp/xsd-2.2.0-no-namespace-dom-patch.zip
http://www.codesynthesis.com/~boris/tmp/xsd-2.2.0-no-namespace-dom-patch.tar.gz

Can try it and let me know if it works in your case? If it does then I
will forward-port this patch for the next version.

Thanks for investigating and 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/20060904/a6421aa6/attachment.pgp
From raulh39 at tid.es  Mon Sep  4 08:48:45 2006
From: raulh39 at tid.es (Raul Huertas)
Date: Sun Oct 11 15:33:48 2009
Subject: [xsd-users] Handling XML data of unknown type
In-Reply-To: <20060904121629.GB8877@karelia>
References: <44FC0D2D.4040009@tid.es> <20060904121629.GB8877@karelia>
Message-ID: <44FC20AD.5040604@tid.es>

Boris Kolpackov escribi?:
> ...
>   
> Can try it and let me know if it works in your case? 
Yes, it works!

But we are only trying XSD and we don't have any big test...

Anyway, I think that the patch should correct the problem.

> If it does then I will forward-port this patch for the next version.
>
> Thanks for investigating and reporting this.
>
>   
You are welcome, and thanks for the quick response. ;)
> -boris
>   
Ra?l.


From boris at codesynthesis.com  Wed Sep  6 04:20:26 2006
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:48 2009
Subject: [xsd-users] Re: Regardin the XSD XML Binder
In-Reply-To: <435a8a590609040548h72f13dafk7293d49bcab3a852@mail.gmail.com>
References: <435a8a590609040548h72f13dafk7293d49bcab3a852@mail.gmail.com>
Message-ID: <20060906082026.GC24434@karelia>

Hi Namratha,

In the future please send technical questions like these to the
xsd-users mailing list. This way a) other developers who may have
experienced a similar problem can provide you with a solution
b) your questions and answers will be archived and be available
to others with similar questions.


namratha priya saldanha <namrathapriyas@gmail.com> writes:

> Hello,
>
> I am Namratha. I downloaded the XSD product for Linux-X86 architecture.
>
> I managed to compile the .xsd file for which  .hxx and .txx files got
> generated.

Ok, from this I gather that you are using the C++/Parser mapping.


> I couldnot understand much from the quick-start guide. I want to know how
> does the .cxx file get generated and what is the driver.cxx file?

With the C++/Parser mapping you do not get the .cxx file. It is
generated for the C++/Tree mapping though. I suggest that you
start with the C++/Tree mapping since it is easier to understand.
The driver.cxx file is a hand-written test case that uses the
generated code.

Also note that both Quick Guides are based on the 'hello' examples
which are available in examples/cxx/tree/hello for C++/Tree and in
/examples/cxx/parser/hello for C++/Parser. The examples also come
with makefiles which I suggest you use in order to build them.


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/20060906/4a53e67c/attachment.pgp
From namrathapriyas at gmail.com  Fri Sep  8 01:46:59 2006
From: namrathapriyas at gmail.com (namratha priya saldanha)
Date: Sun Oct 11 15:33:48 2009
Subject: [xsd-users] Regarding encoding and decoding using XSD
Message-ID: <435a8a590609072246p9ec38edhbe176004a608305e@mail.gmail.com>

Hello,

I downloaded the XSD tool. I am using the C++-parser mapping and i would
want to continue with that.

I would like to know, how do i go about encoding and decoding messages using
XSD. Please revert asap.

Thanks and Regards,
Namratha

From raulh39 at tid.es  Fri Sep  8 02:57:38 2006
From: raulh39 at tid.es (Raul Huertas)
Date: Sun Oct 11 15:33:48 2009
Subject: [xsd-users] Regarding encoding and decoding using XSD
In-Reply-To: <435a8a590609072246p9ec38edhbe176004a608305e@mail.gmail.com>
References: <435a8a590609072246p9ec38edhbe176004a608305e@mail.gmail.com>
Message-ID: <45011462.50903@tid.es>

Have you read this quick guide:
http://codesynthesis.com/projects/xsd/documentation/cxx/parser/quick-guide
?

I think it is a good starting point...
(BTW, at present I prefer to use C++-tree)

namratha priya saldanha escribi?:
> Hello,
>
> I downloaded the XSD tool. I am using the C++-parser mapping and i would
> want to continue with that.
>
> I would like to know, how do i go about encoding and decoding messages 
> using
> XSD. Please revert asap.
>
> Thanks and Regards,
> Namratha
> _______________________________________________
> xsd-users mailing list
> xsd-users@codesynthesis.com
> http://codesynthesis.com/mailman/listinfo/xsd-users
>


From deane at kalotay.com  Fri Sep 15 18:38:30 2006
From: deane at kalotay.com (Deane Yang)
Date: Sun Oct 11 15:33:48 2009
Subject: [xsd-users] New feature
Message-ID: <fefe2c130609151538h43f900f0geaaf4924f41cf104@mail.gmail.com>

Shouldn't it be possible to go the other direction and generate code that
will convert the C++ objects into XML?

From givemenews at tom.com  Sun Sep 17 21:13:01 2006
From: givemenews at tom.com (Lixuesong)
Date: Sun Oct 11 15:33:48 2009
Subject: [xsd-users] bug report for xsd
Message-ID: <000701c6dabf$9814da70$5901a8c0@LJ>

Hi,
  I found a bug on xml schema base64Binary type.
  put the files in the attachment into one directory, then exec the following command:

  xsd cxx-tree --generate-serialization hello.xsd
  g++ -o driver driver.cxx hello.cxx -lxerces-c -lpthread
  ./driver hello.xml

  the output is:

[lxs@mos117 /home/lxs/shay/xsd 1054]$ ./driver hello.xml
<?xml version="1.0" encoding="UTF-8" standalone="no" ?>
<hello>

  <greeting>Hello</greeting>

  <name>xOO6
</name>

</hello>

notice the output between <name> and </name>, why there is a line feed added? 
the output expected should be:  <name>x006</name>

Environment I use:

OS: redhat linux AS3 update4
xsd: version 2.2.0
xerces-c: 2.7.0

Best regards,
Lixuesong
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hello.xsd
Type: application/octet-stream
Size: 341 bytes
Desc: not available
Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20060918/eafe383d/hello.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: driver.cxx
Type: application/octet-stream
Size: 217 bytes
Desc: not available
Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20060918/eafe383d/driver.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hello.xml
Type: text/xml
Size: 209 bytes
Desc: not available
Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20060918/eafe383d/hello.bin
From boris at codesynthesis.com  Mon Sep 18 05:07:56 2006
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:48 2009
Subject: [xsd-users] bug report for xsd
In-Reply-To: <000701c6dabf$9814da70$5901a8c0@LJ>
References: <000701c6dabf$9814da70$5901a8c0@LJ>
Message-ID: <20060918090756.GA7030@karelia>

Hi Lixuesong,

Lixuesong <givemenews@tom.com> writes:

> Hi,
>   I found a bug on xml schema base64Binary type.
>
> ..
>
>   the output is:
>
> [lxs@mos117 /home/lxs/shay/xsd 1054]$ ./driver hello.xml
> <?xml version="1.0" encoding="UTF-8" standalone="no" ?>
> <hello>
>
>   <greeting>Hello</greeting>
>
>   <name>xOO6
> </name>
>
> </hello>
>
> notice the output between <name> and </name>, why there is a line
> feed added?
> the output expected should be:  <name>x006</name>

XML Schema built-in type base64Binary is based on RFC2045 which
defines the Base64 encoding. According to the RFC, it is legal to
add a new line after the last line of encoding. While base64Binary
rules do not require a new line, it would not cause any problems
since this type performs whitespace collapsing (which includes
removing any leading or trailing whitespaces) before decoding. This
is stated in the section 3.2.16 of XML Schema Part2: Datatypes[1]
in the first note.

To summarize, this newline does not cause the content to become
invalid according to XML Schema and is explicitly valid according
to RFC2045. So I would not say this is a bug in XSD. Is it causing
trouble with any other XML Schema or Base64 processors?


[1] http://www.w3.org/TR/xmlschema-2/#base64Binary


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/20060918/bb559e35/attachment.pgp
From boris at codesynthesis.com  Tue Sep 19 03:43:26 2006
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:48 2009
Subject: [xsd-users] XSD 2.3.0 released
Message-ID: <20060919074326.GC23181@karelia>

Good day,


We've released XSD 2.3.0. The NEWS file entries for this version are
as follows:

    * Name conflicts across type inheritance hierarchies are now detected
      and resolved via name escaping.

  C++/Tree

    * New option, --suppress-parsing, suppresses generation of the parsing
      constructors and functions. This can be used to minimize the generated
      code footprint when parsing from XML is not used.

    * New option, --generate-forward, triggers generation of a forward
      declaration header file for types defined in the schema. A set of
      --fwd-* options that control the resulting file name as well as
      prologue and epilogue code are available.

    * New option, --generate-xml-schema, triggers generation of mapping for
      the XML Schema namespace to a separate header file. See the man pages
      for details and examples/cxx/tree/custom/calendar for an example.

    * New option, --extern-xml-schema, triggers inclusion of a header
      file for the XML Schema namespace instead of generating necessary
      declarations inline. See the man pages for details and
      examples/cxx/tree/custom/calendar for an example.

    * New options, --custom-type and --custom-type-regex, instruct the
      compiler to use custom C++ type for a type defined in the schema.
      The standard mapping can still be generated (with a different name)
      usually to be used as a base. Built-in XML Schema types can be
      customized using this mechanism. See the man pages for details and
      examples/cxx/tree/custom/* for examples.

    * The generated parsing constructors and serialization operators have
      been changed to use the Xerces-C++ DOM elements and attributes
      instead of the internal wrapper types. This should provide easier
      integration with other code and libraries that use the Xerces-C++
      DOM types such as Berkeley DB XML.

    * New example, examples/cxx/tree/dbxml, shows how to use the C++/Tree
      mapping on top of the Berkeley DB XML database.

  C++/Parser

    * Validation of the attribute structure in the generated code.

    * Validation of the character content models including mixed content in
      the generated code.

    * Validation of the built-in XML Schema types.

    * Optimizations for space and time in the generated code. In particular
      data coping during parsing and validation was significantly reduced.


With this version we also added support for IBM XL C++ 8.0 compiler and
i686-solaris and powerpc-linux-gnu platforms.

A number of bugs have been fixed in this release. Thanks to the following
individuals for reporting bugs, suggesting fixes and improvements:

Bastien Cojan        <Bastien.Cojan at cadcorp.com>
Remsy Schmilinsky    <Remsy.Schmilinsky at ccra-adrc.gc.ca>
Jos van den Oever    <jvdoever at gmail.com>
Dmitry Trifilov      <dmitry.trifilov at 121media.com>
Lawrence M. Lifshitz <Lawrence.Lifshitz at umassmed.edu>
Raul Huertas         <raulh39 at tid.es>
Sch?r Beat           <beat.schaer at ruag.com>
Deane Yang           <deane at kalotay.com>
Lixuesong            <givemenews at tom.com>


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

  http://codesynthesis.com/products/xsd/download.xhtml


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

  http://codesynthesis.com/projects/xsd/


SHA1 checksums for the files:

7ba80bb40fe6f1506b879cd64aa427cc89d14df0  xsd-2.3.0.tar.bz2
3cb4fd2c6fe192add715c4da55b2381631b84e20  xsd_2.3.0-1_i386.deb
f1580c714bcbfdd79c6243f8fcab1c8e93da26d5  xsd-2.3.0-1.i686.rpm
6187f525041309373ac4e081cbc5227e85a5e655  xsd-2.3.0-i686-linux-gnu.tar.bz2
6f443439c3e658359b4173dad0f14225e1d8287f  xsd_2.3.0-1_amd64.deb
4b9dd6dc3406e81b77efcf4d1f8ff68acf663897  xsd-2.3.0-1.x86_64.rpm
1488dd238258cddbc13e2a75eb5cb332d8f00981  xsd-2.3.0-x86_64-linux-gnu.tar.bz2
0de7e9cd8afaa8be7bdf5b546339ed9915f0825d  xsd-2.3.0-powerpc-linux-gnu.tar.bz2
8f8e85b51e764cd9c6b2db057282692a9e337564  xsd-2.3.0-hppa-hpux.tar.gz
c162907dd4d736f1e4a0ffcb92a5c57c6e0c21ba  xsd-2.3.0-hppa-hpux.tar.bz2
d5e0c9c508b8a8f584e30ea2644fd32ff47524f1  xsd-2.3.0-powerpc-macosx.tar.bz2
227818bd8fc16b1e385a664f9a2a67c065022f5f  xsd-2.3.0-sparc-solaris.tar.gz
a5172df3cc164726bb020f1a9e6d4abb5f41b868  xsd-2.3.0-sparc-solaris.tar.bz2
c195f407b18269c1358769d2b94705771b998e81  xsd-2.3.0-i686-solaris.tar.gz
b1f31d0d8f1c79ba70f3318bcfcca5eb1cbfcf13  xsd-2.3.0-i686-solaris.tar.bz2
13b6682b0a0c9f13c06409736b41f3959bf18f89  xsd-2.3.0-i686-windows.zip



have fun,
-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/20060919/5a8952cd/attachment.pgp
From boris at codesynthesis.com  Tue Sep 19 13:09:08 2006
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:48 2009
Subject: [xsd-users] bug report for xsd
In-Reply-To: <002801c6db8e$65f6cd30$5901a8c0@LJ>
References: <000701c6dabf$9814da70$5901a8c0@LJ> <20060918090756.GA7030@karelia>
	<002801c6db8e$65f6cd30$5901a8c0@LJ>
Message-ID: <20060919170908.GB23756@karelia>

Hi,

In the future please send technical questions like this to the
xsd-users mailing list instead of to me directly. This way a)
other developers who may have experienced a similar problem can
provide you with a solution b) questions and answers will be
archived and available to others with similar problems.


Lixuesong <givemenews@tom.com> writes:

> Yes, the result will not be normal if I use
> std::auto_ptr<hello_type> h (hello (argv[1], xml_schema::flags::dont_validate));
>
> for the following XML file:
>
> <?xml version="1.0" encoding="UTF-8" ?>
> <hello>
>
>   <name>x006
> </name>
>
> </hello>
>
>
> but if I use <name>x006</name>,  the result will be normal.

Confirmed, thanks for reporting this! The patch is available:

http://codesynthesis.com/download/xsd/2.3/xsd-2.3.0-base64-patch.tar.gz
http://codesynthesis.com/download/xsd/2.3/xsd-2.3.0-base64-patch.zip

Note that it is for XSD 2.3.0. To apply follow the instructions in
the README file.


> besides, the result looks ugly if adding adding a line feed before </name>.

We are using base64 encoding functions from Xerces-C++. For some (probably
good) reason their implementation adds the final new line.


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/20060919/99d6ede9/attachment.pgp
From Remsy.Schmilinsky at ccra-adrc.gc.ca  Tue Sep 19 13:40:49 2006
From: Remsy.Schmilinsky at ccra-adrc.gc.ca (Schmilinsky, Remsy)
Date: Sun Oct 11 15:33:48 2009
Subject: [xsd-users] cannot compile libxsd-frontend 1.8.0  cygwin
Message-ID: <D46B9A114A1DAD48B88719C1C1043D80039FE79B@sh24x696.rc.gc.ca>

Hi Boris. I am now trying to compile the latest version of xsd, however
it breaks within libxsd-frontend 1.8.0. Please see the errors below, I
don't think it's necessary to recompile xerces as it was working without
problems with the previous version of xsd.

thanks,

Remsy

[g++]: g++
m4
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/semantic-graph/fundamental.c
xx.m4
m4
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/semantic-graph/fundamental.h
xx.m4
c++ /usr/src/libxsd-frontend-1.8.0/xsd-frontend/semantic-graph/any.cxx
c++
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/semantic-graph/any-attribute
.cxx
c++
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/semantic-graph/attribute.cxx
c++
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/semantic-graph/attribute-gro
up.cxx
c++
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/semantic-graph/complex.cxx
c++
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/semantic-graph/compositors.c
xx
c++
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/semantic-graph/element.cxx
c++
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/semantic-graph/element-group
.cxx
c++
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/semantic-graph/elements.cxx
c++
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/semantic-graph/enumeration.c
xx
c++
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/semantic-graph/fundamental.c
xx
c++ /usr/src/libxsd-frontend-1.8.0/xsd-frontend/semantic-graph/list.cxx
c++
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/semantic-graph/namespace.cxx
c++
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/semantic-graph/particle.cxx
c++
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/semantic-graph/schema.cxx
c++ /usr/src/libxsd-frontend-1.8.0/xsd-frontend/semantic-graph/union.cxx
c++ /usr/src/libxsd-frontend-1.8.0/xsd-frontend/traversal/attribute.cxx
c++
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/traversal/attribute-group.cx
x
c++ /usr/src/libxsd-frontend-1.8.0/xsd-frontend/traversal/complex.cxx
c++
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/traversal/compositors.cxx
c++ /usr/src/libxsd-frontend-1.8.0/xsd-frontend/traversal/element.cxx
c++
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/traversal/element-group.cxx
c++ /usr/src/libxsd-frontend-1.8.0/xsd-frontend/traversal/elements.cxx
c++
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/traversal/enumeration.cxx
c++
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/traversal/fundamental.cxx
c++ /usr/src/libxsd-frontend-1.8.0/xsd-frontend/traversal/list.cxx
c++ /usr/src/libxsd-frontend-1.8.0/xsd-frontend/traversal/namespace.cxx
c++ /usr/src/libxsd-frontend-1.8.0/xsd-frontend/traversal/particle.cxx
c++ /usr/src/libxsd-frontend-1.8.0/xsd-frontend/traversal/schema.cxx
c++ /usr/src/libxsd-frontend-1.8.0/xsd-frontend/traversal/union.cxx
c++ /usr/src/libxsd-frontend-1.8.0/xsd-frontend/parser.cxx
In file included from
/usr/src/xerces-c-src_2_7_0/src/xercesc/validators/datatype/DatatypeVali
dator.hpp:26,
                 from
/usr/src/xerces-c-src_2_7_0/src/xercesc/framework/XMLAttr.hpp:27,
                 from
/usr/src/xerces-c-src_2_7_0/src/xercesc/framework/XMLValidator.hpp:25,
                 from
/usr/src/xerces-c-src_2_7_0/src/xercesc/sax2/SAX2XMLReader.hpp:26,
                 from
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/parser.cxx:24:
/usr/src/xerces-c-src_2_7_0/src/xercesc/util/KVStringPair.hpp:177:
warning: 'void xercesc_2_7::KVStringPair::setKey(const XMLC
h*, unsigned int)' defined locally after being referenced with dllimport
linkage
/usr/src/xerces-c-src_2_7_0/src/xercesc/util/KVStringPair.hpp:190:
warning: 'void xercesc_2_7::KVStringPair::setValue(const XM
LCh*, unsigned int)' defined locally after being referenced with
dllimport linkage
In file included from
/usr/src/xerces-c-src_2_7_0/src/xercesc/validators/schema/ComplexTypeInf
o.hpp:39,
                 from
/usr/src/xerces-c-src_2_7_0/src/xercesc/validators/schema/SchemaElementD
ecl.hpp:27,
                 from
/usr/src/xerces-c-src_2_7_0/src/xercesc/framework/psvi/XSModel.hpp:29,
                 from
/usr/src/xerces-c-src_2_7_0/src/xercesc/framework/XMLGrammarPool.hpp:27,
                 from
/usr/src/xerces-c-src_2_7_0/src/xercesc/validators/common/GrammarResolve
r.hpp:24,
                 from
/usr/src/xerces-c-src_2_7_0/src/xercesc/internal/XMLScanner.hpp:36,
                 from
/usr/src/xerces-c-src_2_7_0/src/xercesc/internal/VecAttributesImpl.hpp:2
8,
                 from
/usr/src/xerces-c-src_2_7_0/src/xercesc/parsers/SAX2XMLReaderImpl.hpp:27
,
                 from
/usr/src/xerces-c-src_2_7_0/src/xercesc/sax2/XMLReaderFactory.hpp:24,
                 from
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/parser.cxx:25:
/usr/src/xerces-c-src_2_7_0/src/xercesc/validators/schema/SchemaAttDef.h
pp:361: warning: 'xercesc_2_7::PSVIDefs::Validation xe
rcesc_2_7::SchemaAttDef::getValidationAttempted() const' defined locally
after being referenced with dllimport linkage
/usr/src/xerces-c-src_2_7_0/src/xercesc/validators/schema/SchemaAttDef.h
pp:386: warning: 'bool xercesc_2_7::SchemaAttDef::getT
ypeAnonymous() const' defined locally after being referenced with
dllimport linkage
/usr/src/xerces-c-src_2_7_0/src/xercesc/validators/schema/SchemaAttDef.h
pp:395: warning: 'bool xercesc_2_7::SchemaAttDef::getM
emberTypeAnonymous() const' defined locally after being referenced with
dllimport linkage
ar /usr/src/libxsd-frontend-1.8.0/xsd-frontend/xsd-frontend.l
c++ /usr/src/libxsd-frontend-1.8.0/tests/driver/driver.cxx
ld /usr/src/libxsd-frontend-1.8.0/tests/driver/driver
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/libxsd-frontend.a(parser.o):
parser.cxx:(.text+0x16809): undefined reference to `__
imp___ZN11xercesc_2_76XMLUni22fgXercescDefaultLocaleE'
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/libxsd-frontend.a(parser.o):
parser.cxx:(.text+0x16811): undefined reference to `__
imp___ZN11xercesc_2_716XMLPlatformUtils10InitializeEPKcS2_PNS_12PanicHan
dlerEPNS_13MemoryManagerEb'
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/libxsd-frontend.a(parser.o):
parser.cxx:(.text+0x1687a): undefined reference to `__
imp___ZN11xercesc_2_716XMLPlatformUtils15fgMemoryManagerE'
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/libxsd-frontend.a(parser.o):
parser.cxx:(.text+0x168d3): undefined reference to `__
imp___ZN11xercesc_2_725DOMImplementationRegistry20getDOMImplementationEP
Kt'
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/libxsd-frontend.a(parser.o):
parser.cxx:(.text+0x168fd): undefined reference to `__
imp___ZN11xercesc_2_716XMLPlatformUtils15fgMemoryManagerE'
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/libxsd-frontend.a(parser.o):
parser.cxx:(.text+0x1695e): undefined reference to `__
imp___ZN11xercesc_2_76XMLUni13fgDOMCommentsE'
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/libxsd-frontend.a(parser.o):
parser.cxx:(.text+0x1698b): undefined reference to `__
imp___ZN11xercesc_2_76XMLUni26fgDOMDatatypeNormalizationE'
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/libxsd-frontend.a(parser.o):
parser.cxx:(.text+0x169b8): undefined reference to `__
imp___ZN11xercesc_2_76XMLUni13fgDOMEntitiesE'
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/libxsd-frontend.a(parser.o):
parser.cxx:(.text+0x169e5): undefined reference to `__
imp___ZN11xercesc_2_76XMLUni15fgDOMNamespacesE'
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/libxsd-frontend.a(parser.o):
parser.cxx:(.text+0x16a12): undefined reference to `__
imp___ZN11xercesc_2_76XMLUni15fgDOMValidationE'
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/libxsd-frontend.a(parser.o):
parser.cxx:(.text+0x16a3f): undefined reference to `__
imp___ZN11xercesc_2_76XMLUni31fgDOMWhitespaceInElementContentE'
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/libxsd-frontend.a(parser.o):
parser.cxx:(.text+0x16a6c): undefined reference to `__
imp___ZN11xercesc_2_76XMLUni14fgXercesSchemaE'
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/libxsd-frontend.a(parser.o):
parser.cxx:(.text+0x16a99): undefined reference to `__
imp___ZN11xercesc_2_76XMLUni26fgXercesSchemaFullCheckingE'
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/libxsd-frontend.a(parser.o):
parser.cxx:(.text+0x16ac6): undefined reference to `__
imp___ZN11xercesc_2_76XMLUni30fgXercesValidationErrorAsFatalE'
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/libxsd-frontend.a(parser.o):
parser.cxx:(.text+0x16b6c): undefined reference to `__
imp___ZN11xercesc_2_716XMLPlatformUtils15fgMemoryManagerE'
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/libxsd-frontend.a(parser.o):
parser.cxx:(.text+0x16b92): undefined reference to `__
imp___ZN11xercesc_2_719Wrapper4InputSourceC1EPNS_11InputSourceEbPNS_13Me
moryManagerE'
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/libxsd-frontend.a(parser.o):
parser.cxx:(.text+0x16e71): undefined reference to `__
imp___ZN11xercesc_2_716XMLPlatformUtils15fgMemoryManagerE'
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/libxsd-frontend.a(parser.o):
parser.cxx:(.text+0x16e83): undefined reference to `__
imp___ZN11xercesc_2_77XMemorynwEjPNS_13MemoryManagerE'
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/libxsd-frontend.a(parser.o):
parser.cxx:(.text+0x16ea2): undefined reference to `__
imp___ZN11xercesc_2_716XMLPlatformUtils15fgMemoryManagerE'
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/libxsd-frontend.a(parser.o):
parser.cxx:(.text+0x16ebe): undefined reference to `__
imp___ZN11xercesc_2_712XSDDOMParserC1EPNS_12XMLValidatorEPNS_13MemoryMan
agerEPNS_14XMLGrammarPoolE'
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/libxsd-frontend.a(parser.o):
parser.cxx:(.text+0x16ee9): undefined reference to `__
imp___ZN11xercesc_2_716XMLPlatformUtils15fgMemoryManagerE'
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/libxsd-frontend.a(parser.o):
parser.cxx:(.text+0x16efd): undefined reference to `__
imp___ZN11xercesc_2_77XMemorydlEPvPNS_13MemoryManagerE'
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/libxsd-frontend.a(parser.o):
parser.cxx:(.text+0x16f70): undefined reference to `__
imp___ZN11xercesc_2_717AbstractDOMParser19setValidationSchemeENS0_10ValS
chemesE'
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/libxsd-frontend.a(parser.o):
parser.cxx:(.text+0x16f90): undefined reference to `__
imp___ZN11xercesc_2_717AbstractDOMParser15setDoNamespacesEb'
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/libxsd-frontend.a(parser.o):
parser.cxx:(.text+0x16fb2): undefined reference to `__
imp___ZN11xercesc_2_717AbstractDOMParser5parseERKNS_11InputSourceE'
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/libxsd-frontend.a(parser.o):
parser.cxx:(.text+0x16fca): undefined reference to `__
imp___ZN11xercesc_2_717AbstractDOMParser13adoptDocumentEv'
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/libxsd-frontend.a(parser.o):
parser.cxx:(.text+0x17347): undefined reference to `__
imp___ZN11xercesc_2_717DOMImplementation19loadDOMExceptionMsgENS_12DOMEx
ception13ExceptionCodeEPtj'
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/libxsd-frontend.a(parser.o):
parser.cxx:(.text$_ZN11XSDFrontend3XML11XMLChStringD1E
v[XSDFrontend::XML::XMLChString::~XMLChString()]+0xd): undefined
reference to `__imp___ZN11xercesc_2_79XMLString7releaseEPPt'
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/libxsd-frontend.a(parser.o):
parser.cxx:(.text$_ZN11XSDFrontend3XML19transcode_to_n
arrowEPKt[XSDFrontend::XML::transcode_to_narrow(unsigned short
const*)]+0x3c): undefined reference to `__imp___ZN11xercesc_2_7
9XMLString9transcodeEPKt'
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/libxsd-frontend.a(parser.o):
parser.cxx:(.text$_ZN11XSDFrontend3XML19transcode_to_n
arrowEPKt[XSDFrontend::XML::transcode_to_narrow(unsigned short
const*)]+0x65): undefined reference to `__imp___ZN11xercesc_2_7
9XMLString7releaseEPPc'
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/libxsd-frontend.a(parser.o):
parser.cxx:(.text$_ZN11XSDFrontend11InputSourceD1Ev[XS
DFrontend::InputSource::~InputSource()]+0xf1): undefined reference to
`__imp___ZN11xercesc_2_711InputSourceD2Ev'
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/libxsd-frontend.a(parser.o):
parser.cxx:(.text$_ZN11XSDFrontend11InputSourceD1Ev[XS
DFrontend::InputSource::~InputSource()]+0x11d): undefined reference to
`__imp___ZN11xercesc_2_711InputSourceD2Ev'
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/libxsd-frontend.a(parser.o):
parser.cxx:(.text$_ZN11XSDFrontend11InputSourceD1Ev[XS
DFrontend::InputSource::~InputSource()]+0x13d): undefined reference to
`__imp___ZN11xercesc_2_77XMemorydlEPv'
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/libxsd-frontend.a(parser.o):
parser.cxx:(.text$_ZN11XSDFrontend14EntityResolverD1Ev
[XSDFrontend::EntityResolver::~EntityResolver()]+0x2d): undefined
reference to `__imp___ZN11xercesc_2_77XMemorydlEPv'
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/libxsd-frontend.a(parser.o):
parser.cxx:(.text$_ZN11XSDFrontend11InputSourceC1ERKN5
boost10filesystem4pathES5_S5_RKNS_7ContextEPN11xercesc_2_713MemoryManage
rE[XSDFrontend::InputSource::InputSource(boost::filesy
stem::path const&, boost::filesystem::path const&,
boost::filesystem::path const&, XSDFrontend::Context const&,
xercesc_2_7::M
emoryManager*)]+0x52): undefined reference to
`__imp___ZN11xercesc_2_711InputSourceC2EPNS_13MemoryManagerE'
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/libxsd-frontend.a(parser.o):
parser.cxx:(.text$_ZN11XSDFrontend11InputSourceC1ERKN5
boost10filesystem4pathES5_S5_RKNS_7ContextEPN11xercesc_2_713MemoryManage
rE[XSDFrontend::InputSource::InputSource(boost::filesy
stem::path const&, boost::filesystem::path const&,
boost::filesystem::path const&, XSDFrontend::Context const&,
xercesc_2_7::M
emoryManager*)]+0x335): undefined reference to
`__imp___ZN11xercesc_2_711InputSourceD2Ev'
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/libxsd-frontend.a(parser.o):
parser.cxx:(.text$_ZNK11XSDFrontend11InputSource10make
StreamEv[XSDFrontend::InputSource::makeStream() const]+0x7c): undefined
reference to `__imp___ZN11xercesc_2_77XMemorynwEjPNS_1
3MemoryManagerE'
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/libxsd-frontend.a(parser.o):
parser.cxx:(.text$_ZNK11XSDFrontend11InputSource10make
StreamEv[XSDFrontend::InputSource::makeStream() const]+0x9a): undefined
reference to `__imp___ZN11xercesc_2_718BinFileInputStr
eamC1EPKtPNS_13MemoryManagerE'
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/libxsd-frontend.a(parser.o):
parser.cxx:(.text$_ZNK11XSDFrontend11InputSource10make
StreamEv[XSDFrontend::InputSource::makeStream() const]+0xc6): undefined
reference to `__imp___ZN11xercesc_2_77XMemorydlEPvPNS_
13MemoryManagerE'
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/libxsd-frontend.a(parser.o):
parser.cxx:(.text$_ZN11XSDFrontend11InputSourceD0Ev[XS
DFrontend::InputSource::~InputSource()]+0xf1): undefined reference to
`__imp___ZN11xercesc_2_711InputSourceD2Ev'
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/libxsd-frontend.a(parser.o):
parser.cxx:(.text$_ZN11XSDFrontend11InputSourceD0Ev[XS
DFrontend::InputSource::~InputSource()]+0x11d): undefined reference to
`__imp___ZN11xercesc_2_711InputSourceD2Ev'
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/libxsd-frontend.a(parser.o):
parser.cxx:(.text$_ZN11XSDFrontend11InputSourceD0Ev[XS
DFrontend::InputSource::~InputSource()]+0x13d): undefined reference to
`__imp___ZN11xercesc_2_77XMemorydlEPv'
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/libxsd-frontend.a(parser.o):
parser.cxx:(.text$_ZN11XSDFrontend14EntityResolver13re
solveEntityEPKtS2_S2_[XSDFrontend::EntityResolver::resolveEntity(unsigne
d short const*, unsigned short const*, unsigned short
const*)]+0x53d): undefined reference to
`__imp___ZN11xercesc_2_716XMLPlatformUtils15fgMemoryManagerE'
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/libxsd-frontend.a(parser.o):
parser.cxx:(.text$_ZN11XSDFrontend14EntityResolver13re
solveEntityEPKtS2_S2_[XSDFrontend::EntityResolver::resolveEntity(unsigne
d short const*, unsigned short const*, unsigned short
const*)]+0x54f): undefined reference to
`__imp___ZN11xercesc_2_77XMemorynwEjPNS_13MemoryManagerE'
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/libxsd-frontend.a(parser.o):
parser.cxx:(.text$_ZN11XSDFrontend14EntityResolver13re
solveEntityEPKtS2_S2_[XSDFrontend::EntityResolver::resolveEntity(unsigne
d short const*, unsigned short const*, unsigned short
const*)]+0x55c): undefined reference to
`__imp___ZN11xercesc_2_716XMLPlatformUtils15fgMemoryManagerE'
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/libxsd-frontend.a(parser.o):
parser.cxx:(.text$_ZN11XSDFrontend14EntityResolver13re
solveEntityEPKtS2_S2_[XSDFrontend::EntityResolver::resolveEntity(unsigne
d short const*, unsigned short const*, unsigned short
const*)]+0x5be): undefined reference to
`__imp___ZN11xercesc_2_716XMLPlatformUtils15fgMemoryManagerE'
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/libxsd-frontend.a(parser.o):
parser.cxx:(.text$_ZN11XSDFrontend14EntityResolver13re
solveEntityEPKtS2_S2_[XSDFrontend::EntityResolver::resolveEntity(unsigne
d short const*, unsigned short const*, unsigned short
const*)]+0x5d2): undefined reference to
`__imp___ZN11xercesc_2_77XMemorydlEPvPNS_13MemoryManagerE'
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/libxsd-frontend.a(parser.o):
parser.cxx:(.text$_ZN11XSDFrontend14EntityResolver13re
solveEntityEPKtS2_S2_[XSDFrontend::EntityResolver::resolveEntity(unsigne
d short const*, unsigned short const*, unsigned short
const*)]+0x628): undefined reference to
`__imp___ZN11xercesc_2_716XMLPlatformUtils15fgMemoryManagerE'
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/libxsd-frontend.a(parser.o):
parser.cxx:(.text$_ZN11XSDFrontend14EntityResolver13re
solveEntityEPKtS2_S2_[XSDFrontend::EntityResolver::resolveEntity(unsigne
d short const*, unsigned short const*, unsigned short
const*)]+0x64e): undefined reference to
`__imp___ZN11xercesc_2_719Wrapper4InputSourceC1EPNS_11InputSourceEbPNS_1
3MemoryManager
E'
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/libxsd-frontend.a(parser.o):
parser.cxx:(.text$_ZN11XSDFrontend14EntityResolverD0Ev
[XSDFrontend::EntityResolver::~EntityResolver()]+0x2d): undefined
reference to `__imp___ZN11xercesc_2_77XMemorydlEPv'
/usr/src/xerces-c-src_2_7_0/lib/libxerces-c.a(XMLString.o):XMLString.cpp
:(.text+0x2773): undefined reference to `___errno'
/usr/src/xerces-c-src_2_7_0/lib/libxerces-c.a(XMLString.o):XMLString.cpp
:(.text+0x27e9): undefined reference to `___errno'
/usr/src/xerces-c-src_2_7_0/lib/libxerces-c.a(XMLString.o):XMLString.cpp
:(.text+0x2b6f): undefined reference to `___errno'
/usr/src/xerces-c-src_2_7_0/lib/libxerces-c.a(XMLString.o):XMLString.cpp
:(.text+0x2c9a): undefined reference to `___errno'
/usr/src/xerces-c-src_2_7_0/lib/libxerces-c.a(CygwinPlatformUtils.o):Cyg
winPlatformUtils.cpp:(.text+0xa0c): undefined referenc
e to `_cygwin_conv_to_posix_path'
/usr/src/xerces-c-src_2_7_0/lib/libxerces-c.a(CygwinPlatformUtils.o):Cyg
winPlatformUtils.cpp:(.text+0xaed): undefined referenc
e to `_cygwin_conv_to_posix_path'
/usr/src/xerces-c-src_2_7_0/lib/libxerces-c.a(CygwinPlatformUtils.o):Cyg
winPlatformUtils.cpp:(.text+0xbc2): undefined referenc
e to `_cygwin_conv_to_posix_path'
/usr/src/xerces-c-src_2_7_0/lib/libxerces-c.a(CygwinPlatformUtils.o):Cyg
winPlatformUtils.cpp:(.text+0xc71): undefined referenc
e to `_cygwin_conv_to_posix_path'
/usr/src/xerces-c-src_2_7_0/lib/libxerces-c.a(CygwinPlatformUtils.o):Cyg
winPlatformUtils.cpp:(.text+0x1150): undefined referen
ce to `_cygwin_conv_to_full_posix_path'
/usr/src/xerces-c-src_2_7_0/lib/libxerces-c.a(DefaultPanicHandler.o):Def
aultPanicHandler.cpp:(.text+0x15): undefined reference
 to `___getreent'
/usr/src/xerces-c-src_2_7_0/lib/libxerces-c.a(XSValue.o):XSValue.cpp:(.t
ext+0x4b62): undefined reference to `___errno'
/usr/src/xerces-c-src_2_7_0/lib/libxerces-c.a(XSValue.o):XSValue.cpp:(.t
ext+0x4c82): undefined reference to `___errno'
/usr/src/xerces-c-src_2_7_0/lib/libxerces-c.a(XSValue.o):XSValue.cpp:(.t
ext+0x4d34): undefined reference to `___errno'
/usr/src/xerces-c-src_2_7_0/lib/libxerces-c.a(XSValue.o):XSValue.cpp:(.t
ext+0x4e07): undefined reference to `___errno'
/usr/src/xerces-c-src_2_7_0/lib/libxerces-c.a(UnixHTTPURLInputStream.o):
UnixHTTPURLInputStream.cpp:(.text+0x85a): undefined re
ference to `_gethostbyname'
/usr/src/xerces-c-src_2_7_0/lib/libxerces-c.a(UnixHTTPURLInputStream.o):
UnixHTTPURLInputStream.cpp:(.text+0x870): undefined re
ference to `_inet_addr'
/usr/src/xerces-c-src_2_7_0/lib/libxerces-c.a(UnixHTTPURLInputStream.o):
UnixHTTPURLInputStream.cpp:(.text+0x894): undefined re
ference to `_gethostbyaddr'
/usr/src/xerces-c-src_2_7_0/lib/libxerces-c.a(UnixHTTPURLInputStream.o):
UnixHTTPURLInputStream.cpp:(.text+0xa07): undefined re
ference to `_socket'
/usr/src/xerces-c-src_2_7_0/lib/libxerces-c.a(UnixHTTPURLInputStream.o):
UnixHTTPURLInputStream.cpp:(.text+0xb61): undefined re
ference to `_connect'
/usr/src/xerces-c-src_2_7_0/lib/libxerces-c.a(UnixHTTPURLInputStream.o):
UnixHTTPURLInputStream.cpp:(.text+0x2742): undefined r
eference to `_gethostbyname'
/usr/src/xerces-c-src_2_7_0/lib/libxerces-c.a(UnixHTTPURLInputStream.o):
UnixHTTPURLInputStream.cpp:(.text+0x2758): undefined r
eference to `_inet_addr'
/usr/src/xerces-c-src_2_7_0/lib/libxerces-c.a(UnixHTTPURLInputStream.o):
UnixHTTPURLInputStream.cpp:(.text+0x277c): undefined r
eference to `_gethostbyaddr'
/usr/src/xerces-c-src_2_7_0/lib/libxerces-c.a(UnixHTTPURLInputStream.o):
UnixHTTPURLInputStream.cpp:(.text+0x28ef): undefined r
eference to `_socket'
/usr/src/xerces-c-src_2_7_0/lib/libxerces-c.a(UnixHTTPURLInputStream.o):
UnixHTTPURLInputStream.cpp:(.text+0x2a49): undefined r
eference to `_connect'
/usr/src/xerces-c-src_2_7_0/lib/libxerces-c.a(UnixHTTPURLInputStream.o):
UnixHTTPURLInputStream.cpp:(.text+0x3e2d): undefined r
eference to `_shutdown'
/usr/src/xerces-c-src_2_7_0/lib/libxerces-c.a(UnixHTTPURLInputStream.o):
UnixHTTPURLInputStream.cpp:(.text+0x3ef5): undefined r
eference to `_shutdown'
/usr/src/xerces-c-src_2_7_0/lib/libxerces-c.a(UnixHTTPURLInputStream.o):
UnixHTTPURLInputStream.cpp:(.text+0x3fbd): undefined r
eference to `_shutdown'
/usr/src/xerces-c-src_2_7_0/lib/libxerces-c.a(XMLAbstractDoubleFloat.o):
XMLAbstractDoubleFloat.cpp:(.text+0x11ba): undefined r
eference to `___errno'
/usr/src/xerces-c-src_2_7_0/lib/libxerces-c.a(XMLAbstractDoubleFloat.o):
XMLAbstractDoubleFloat.cpp:(.text+0x12b6): undefined r
eference to `___errno'
collect2: ld returned 1 exit status
make: *** [/usr/src/libxsd-frontend-1.8.0/tests/driver/driver] Error 1


From boris at codesynthesis.com  Tue Sep 19 13:46:17 2006
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:48 2009
Subject: [xsd-users] New feature
In-Reply-To: <fefe2c130609151538h43f900f0geaaf4924f41cf104@mail.gmail.com>
References: <fefe2c130609151538h43f900f0geaaf4924f41cf104@mail.gmail.com>
Message-ID: <20060919174617.GC23756@karelia>

Hi Deane,

Deane Yang <deane@kalotay.com> writes:

> Shouldn't it be possible to go the other direction and generate code that
> will convert the C++ objects into XML?

This questions can be interpreted in two different ways:

1. Can the objects generated from XML Schema (using C++/Tree mapping)
   be serialized to XML? The answer is yes. You will need to use the
   --generate-serialization option when translating your schemas. The
   library example in examples/cxx/tree/library shows how to do it.
   There is also a separate chapter on serialization in the manual.


2. Is it possible to automatically generate some code that will
   serialize arbitrary C++ object to XML? The answer is no, at least
   not with XSD.

   It is also seldom a good idea to do it this way. The main reason
   why you should choose XML is because it is universal enough and
   self-descriptive enough that other applications, perhaps written
   in other languages and running on other platforms, can parse and
   understand the information stored in it. In other words, it does
   not make sense to use XML (there are more efficient formats both
   to parse and space-wise) if it is only your application that is
   going to ever read it.

   Now if there are going to be other applications that will need
   to understand your XML-based format then you will probably need
   some formal specification for it. If your XML is written with
   the help of a tool that parses C++ objects and produces code
   to serialize them then those C++ objects are your specification:
   when they change your XML changes. Imagine now telling your
   other department (who, say, are using PHP) or, even better, your
   customer that they should read your C++ headers to figure out what
   the XML will look like ;-).


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/20060919/aa740c21/attachment.pgp
From boris at codesynthesis.com  Tue Sep 19 13:55:25 2006
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:48 2009
Subject: [xsd-users] cannot compile libxsd-frontend 1.8.0  cygwin
In-Reply-To: <D46B9A114A1DAD48B88719C1C1043D80039FE79B@sh24x696.rc.gc.ca>
References: <D46B9A114A1DAD48B88719C1C1043D80039FE79B@sh24x696.rc.gc.ca>
Message-ID: <20060919175525.GD23756@karelia>

Hi Remsy,

Schmilinsky, Remsy <Remsy.Schmilinsky@ccra-adrc.gc.ca> writes:

> Hi Boris. I am now trying to compile the latest version of xsd, however
> it breaks within libxsd-frontend 1.8.0. Please see the errors below, I
> don't think it's necessary to recompile xerces as it was working without
> problems with the previous version of xsd.
>
> ...
>
> /usr/src/xerces-c-src_2_7_0/src/xercesc/util/KVStringPair.hpp:177:
> warning: 'void xercesc_2_7::KVStringPair::setKey(const XMLC
> h*, unsigned int)' defined locally after being referenced with dllimport
> linkage
>
> ...
>
> /usr/src/libxsd-frontend-1.8.0/xsd-frontend/libxsd-frontend.a(parser.o):
> parser.cxx:(.text+0x16809): undefined reference to `__
> imp___ZN11xercesc_2_76XMLUni22fgXercescDefaultLocaleE'

I am pretty sure you are using a build of Xerces-C++ that was not built
according to the instructions for Windows[1]. All this dllimport/dllexport
stuff should have been commented out in the GCCDefs.hpp.


[1] http://codesynthesis.com/projects/xsd/extras/build-windows.xhtml

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/20060919/6b8d869a/attachment.pgp
From Remsy.Schmilinsky at ccra-adrc.gc.ca  Tue Sep 19 14:12:56 2006
From: Remsy.Schmilinsky at ccra-adrc.gc.ca (Schmilinsky, Remsy)
Date: Sun Oct 11 15:33:48 2009
Subject: [xsd-users] cannot compile libxsd-frontend 1.8.0  cygwin
Message-ID: <D46B9A114A1DAD48B88719C1C1043D80039FE79D@sh24x696.rc.gc.ca>

Sorry for the confusion. The problem is that we need to recompile xerces
with other options in order to run the examples.

remsy

-----Original Message-----
From: Boris Kolpackov [mailto:boris@codesynthesis.com]
Sent: September 19, 2006 1:55 PM
To: Schmilinsky, Remsy
Cc: xsd-users@codesynthesis.com
Subject: Re: [xsd-users] cannot compile libxsd-frontend 1.8.0 cygwin


Hi Remsy,

Schmilinsky, Remsy <Remsy.Schmilinsky@ccra-adrc.gc.ca> writes:

> Hi Boris. I am now trying to compile the latest version of xsd,
however
> it breaks within libxsd-frontend 1.8.0. Please see the errors below, I
> don't think it's necessary to recompile xerces as it was working
without
> problems with the previous version of xsd.
>
> ...
>
> /usr/src/xerces-c-src_2_7_0/src/xercesc/util/KVStringPair.hpp:177:
> warning: 'void xercesc_2_7::KVStringPair::setKey(const XMLC
> h*, unsigned int)' defined locally after being referenced with
dllimport
> linkage
>
> ...
>
>
/usr/src/libxsd-frontend-1.8.0/xsd-frontend/libxsd-frontend.a(parser.o):
> parser.cxx:(.text+0x16809): undefined reference to `__
> imp___ZN11xercesc_2_76XMLUni22fgXercescDefaultLocaleE'

I am pretty sure you are using a build of Xerces-C++ that was not built
according to the instructions for Windows[1]. All this
dllimport/dllexport
stuff should have been commented out in the GCCDefs.hpp.


[1] http://codesynthesis.com/projects/xsd/extras/build-windows.xhtml

hth,
-boris


From deane at kalotay.com  Tue Sep 19 14:18:11 2006
From: deane at kalotay.com (Deane Yang)
Date: Sun Oct 11 15:33:48 2009
Subject: [xsd-users] New feature
In-Reply-To: <20060919174617.GC23756@karelia>
References: <fefe2c130609151538h43f900f0geaaf4924f41cf104@mail.gmail.com>
	<20060919174617.GC23756@karelia>
Message-ID: <45103463.1030301@kalotay.com>

Boris,

Thank you very much for your response. I just had one quick small 
question below.

Boris Kolpackov wrote:
> Deane Yang <deane@kalotay.com> writes:
>
>   
>> Shouldn't it be possible to go the other direction and generate code that
>> will convert the C++ objects into XML?
>>     
>
> This questions can be interpreted in two different ways:
>
> 1. Can the objects generated from XML Schema (using C++/Tree mapping)
>    be serialized to XML? The answer is yes. You will need to use the
>    --generate-serialization option when translating your schemas. The
>    library example in examples/cxx/tree/library shows how to do it.
>    There is also a separate chapter on serialization in the manual.
>   

I just noticed this part of the manual, and it does look like what I was 
asking for. I just wanted to confirm that a round trip works, namely:
C++ object -> XML -> C++ object
results in the same object as the original.

>
> 2. Is it possible to automatically generate some code that will
>    serialize arbitrary C++ object to XML? The answer is no, at least
>    not with XSD.
>   

No, I didn't mean this. Your response is interesting, however.

Regards,
Deane

From boris at codesynthesis.com  Tue Sep 19 14:31:57 2006
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:48 2009
Subject: [xsd-users] New feature
In-Reply-To: <45103463.1030301@kalotay.com>
References: <fefe2c130609151538h43f900f0geaaf4924f41cf104@mail.gmail.com>
	<20060919174617.GC23756@karelia> <45103463.1030301@kalotay.com>
Message-ID: <20060919183157.GE23756@karelia>

Deane,

Deane Yang <deane@kalotay.com> writes:

> >1. Can the objects generated from XML Schema (using C++/Tree mapping)
> >   be serialized to XML? The answer is yes. You will need to use the
> >   --generate-serialization option when translating your schemas. The
> >   library example in examples/cxx/tree/library shows how to do it.
> >   There is also a separate chapter on serialization in the manual.
> >
>
> I just noticed this part of the manual, and it does look like what I was
> asking for. I just wanted to confirm that a round trip works, namely:
> C++ object -> XML -> C++ object
> results in the same object as the original.

Yes, that's how it works. You can also save to a binary format (e.g.,
CDR): C++ object-> Binary -> C++ object.


> >2. Is it possible to automatically generate some code that will
> >   serialize arbitrary C++ object to XML? The answer is no, at least
> >   not with XSD.
> >
>
> No, I didn't mean this. Your response is interesting, however.

I was thinking about all this lately and I guess my mind seized the
opportunity ;-).


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/20060919/a5e5a9a8/attachment.pgp
From boris at codesynthesis.com  Tue Sep 19 14:37:19 2006
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:48 2009
Subject: [xsd-users] cannot compile libxsd-frontend 1.8.0  cygwin
In-Reply-To: <D46B9A114A1DAD48B88719C1C1043D80039FE79D@sh24x696.rc.gc.ca>
References: <D46B9A114A1DAD48B88719C1C1043D80039FE79D@sh24x696.rc.gc.ca>
Message-ID: <20060919183719.GF23756@karelia>

Remsy,

Schmilinsky, Remsy <Remsy.Schmilinsky@ccra-adrc.gc.ca> writes:

> Sorry for the confusion. The problem is that we need to recompile xerces
> with other options in order to run the examples.

Yes, I remember. I suggest that you simply keep two separate builds of
Xerces-C++ - one for XSD (MinGW) and one for your applications (Cygwin).
Since XSD links statically to Xerces-C++ you don't need to install this
version of Xerces-C++ (e.g., copy it to /usr/local) so you can just
install the one that you will use to build your applications.


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/20060919/80006203/attachment.pgp
From boris at codesynthesis.com  Tue Sep 19 17:13:18 2006
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:49 2009
Subject: [xsd-users] New feature
In-Reply-To: <45105633.2040006@kalotay.com>
References: <fefe2c130609151538h43f900f0geaaf4924f41cf104@mail.gmail.com>
	<20060919174617.GC23756@karelia> <45103463.1030301@kalotay.com>
	<20060919183157.GE23756@karelia> <45105633.2040006@kalotay.com>
Message-ID: <20060919211318.GA26357@karelia>

Hi Deane,

Deane Yang <deane@kalotay.com> writes:

> I've almost got this working, but I can't quite figure out the namespace
> stuff. How do I set "noNamespaceSchemaLocation"?
>
> If I do something like
>
> xml_schema::namespace_infomap map;
>
> map["t"].name = "";
> map["t"].schema = "test.xsd";

That would be

map[""].schema = "test.xsd";

I guess we need to add this to the manual since it surely isn't obvious.


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/20060919/f132b824/attachment.pgp
From deane at kalotay.com  Tue Sep 19 16:42:27 2006
From: deane at kalotay.com (Deane Yang)
Date: Sun Oct 11 15:33:49 2009
Subject: [xsd-users] New feature
In-Reply-To: <20060919183157.GE23756@karelia>
References: <fefe2c130609151538h43f900f0geaaf4924f41cf104@mail.gmail.com>
	<20060919174617.GC23756@karelia> <45103463.1030301@kalotay.com>
	<20060919183157.GE23756@karelia>
Message-ID: <45105633.2040006@kalotay.com>

Boris,

Boris Kolpackov wrote:
>> I just noticed this part of the manual, and it does look like what I was
>> asking for. I just wanted to confirm that a round trip works, namely:
>> C++ object -> XML -> C++ object
>> results in the same object as the original.
>>     
>
> Yes, that's how it works. You can also save to a binary format (e.g.,
> CDR): C++ object-> Binary -> C++ object.
>   
I've almost got this working, but I can't quite figure out the namespace 
stuff. How do I set "noNamespaceSchemaLocation"?

If I do something like

xml_schema::namespace_infomap map;

map["t"].name = "";
map["t"].schema = "test.xsd";

then the XML file generated contains 
"noNamespaceSchemaLocation="test.xsd"", but it also contains 
"xmlns:t=""", so when I run that through XSD, XSD complains that the 
value of this attribute is invalid.

And, if I set the name to something nonempty, then of course, it sets 
SchemaLocation and not noNamespaceSchemaLocation.

Any help you can provide for this would be greatly appreciated.

Regards,
Deane

-- 
Deane Yang
Head of Research
Andrew Kalotay Associates
61 Broadway, Suite 1400
New York NY 10006
Tel: 212 482 0900, then press 5
Email: deane@kalotay.com
Web: http://www.kalotay.com


From boris at codesynthesis.com  Thu Sep 21 09:49:26 2006
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:49 2009
Subject: [xsd-users] Support for GML 3.1.1 in XSD 2.3.0
Message-ID: <20060921134926.GB10327@karelia>

Good day,

For the release of XSD 2.3.0 we've fixed the bug in Xerces-C++ that
prevented Xerces-C++ (and thus XSD) from validating GML schemas. All
precompiled binaries of XSD from 2.3.0 are built with this fix.

We've also started a Wiki page for GML that discusses other aspects
of using XSD to translate GML schemas:


http://wiki.codesynthesis.com/Schemas/GML


have fun,
-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/20060921/255d8dc5/attachment.pgp
From Remsy.Schmilinsky at ccra-adrc.gc.ca  Fri Sep 22 10:26:33 2006
From: Remsy.Schmilinsky at ccra-adrc.gc.ca (Schmilinsky, Remsy)
Date: Sun Oct 11 15:33:49 2009
Subject: [xsd-users] serialize library objects to ofstream
Message-ID: <D46B9A114A1DAD48B88719C1C1043D80039FE7B2@sh24x696.rc.gc.ca>

Hi. I'm trying to combine the library and streaming examples so that I can serialize books into an xml file from memory representation. The code below compiles fine, but when I run it I get "no mapping provided for a namespace".

I compile library.xsd like this:

/usr/local/bin/xsd cxx-tree --generate-inline --generate-ostream --generate-serialization --suppress-parsing --root-element-all library.xsd

please help

        std::ofstream ofs;
        ofs.exceptions (ios_base::badbit | ios_base::failbit);
        ofs.open ("out.xml");
        
        ofs << "<?xml version=\"1.0\" encoding=\"UTF-8\"?>" << endl
        << "<lib:catalog>" << endl;        
        
        xercesc::XMLPlatformUtils::Initialize ();
        
        xml_schema::namespace_infomap map;
        
        catalog c;
        
        book b(20530902,                // ISBN
        title("The Elements of Style"), // Title
        genre::reference,               // Genre
        "ES");                          // ID
        
        author strunk("William Strunk, Jr.", "1869-07-01");
        strunk.died("1946-09-26");
        
        b.author().push_back(strunk);
        c.book().push_back(b);
        
        catalog_ (ofs,
                  c,
                  map,
                  "UTF-8",
                  xml_schema::flags::dont_initialize |
                  xml_schema::flags::no_xml_declaration);
                  
        ofs << "</lib:catalog>" << endl;
        
        xercesc::XMLPlatformUtils::Terminate ();

From Remsy.Schmilinsky at ccra-adrc.gc.ca  Fri Sep 22 10:42:45 2006
From: Remsy.Schmilinsky at ccra-adrc.gc.ca (Schmilinsky, Remsy)
Date: Sun Oct 11 15:33:49 2009
Subject: [xsd-users] serialize library objects to ofstream
Message-ID: <D46B9A114A1DAD48B88719C1C1043D80039FE7B3@sh24x696.rc.gc.ca>

I forgot to include these below line xml_schema::namespace_infomap map;:

        map["lib"].name = "http://www.codesynthesis.com/library";
        map["lib"].schema = "library.xsd";        

so problem resolved !

-----Original Message-----
From: xsd-users-bounces@codesynthesis.com
[mailto:xsd-users-bounces@codesynthesis.com]
Sent: September 22, 2006 10:27 AM
To: xsd-users@codesynthesis.com
Subject: [xsd-users] serialize library objects to ofstream


Hi. I'm trying to combine the library and streaming examples so that I can serialize books into an xml file from memory representation. The code below compiles fine, but when I run it I get "no mapping provided for a namespace".

I compile library.xsd like this:

/usr/local/bin/xsd cxx-tree --generate-inline --generate-ostream --generate-serialization --suppress-parsing --root-element-all library.xsd

please help

        std::ofstream ofs;
        ofs.exceptions (ios_base::badbit | ios_base::failbit);
        ofs.open ("out.xml");
        
        ofs << "<?xml version=\"1.0\" encoding=\"UTF-8\"?>" << endl
        << "<lib:catalog>" << endl;        
        
        xercesc::XMLPlatformUtils::Initialize ();
        
        xml_schema::namespace_infomap map;
        
        catalog c;
        
        book b(20530902,                // ISBN
        title("The Elements of Style"), // Title
        genre::reference,               // Genre
        "ES");                          // ID
        
        author strunk("William Strunk, Jr.", "1869-07-01");
        strunk.died("1946-09-26");
        
        b.author().push_back(strunk);
        c.book().push_back(b);
        
        catalog_ (ofs,
                  c,
                  map,
                  "UTF-8",
                  xml_schema::flags::dont_initialize |
                  xml_schema::flags::no_xml_declaration);
                  
        ofs << "</lib:catalog>" << endl;
        
        xercesc::XMLPlatformUtils::Terminate ();
_______________________________________________
xsd-users mailing list
xsd-users@codesynthesis.com
http://codesynthesis.com/mailman/listinfo/xsd-users


From boris at codesynthesis.com  Fri Sep 22 11:17:38 2006
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:49 2009
Subject: [xsd-users] serialize library objects to ofstream
In-Reply-To: <D46B9A114A1DAD48B88719C1C1043D80039FE7B3@sh24x696.rc.gc.ca>
References: <D46B9A114A1DAD48B88719C1C1043D80039FE7B3@sh24x696.rc.gc.ca>
Message-ID: <20060922151738.GA15639@karelia>

Hi Remsy,

Schmilinsky, Remsy <Remsy.Schmilinsky@ccra-adrc.gc.ca> writes:

>         map["lib"].name = "http://www.codesynthesis.com/library";
>         map["lib"].schema = "library.xsd";

I am glad you managed to answer your own question. You probably
would want to omit specifying the schema (the last line) since
the schemaLocation declaration only makes sense in the root
element. Instead you may want to add the needed attributes to
the root element (see below).


> ofs << "<?xml version=\"1.0\" encoding=\"UTF-8\"?>" << endl
>     << "<lib:catalog>" << endl;
>

Note that the resulting XML won't be valid with regards to XML
namespaces because you haven't provided the mapping for prefix
'lib:' in the root element. You can fix this by replacing the
code above with something like this:

ofs << "<?xml version=\"1.0\" encoding=\"UTF-8\"?>" << endl
    << "<lib:catalog xmlns:lib=\"http://www.codesynthesis.com/library\">"
    << endl;


If you also want to specify the schema location then it becomes:


ofs << "<?xml version=\"1.0\" encoding=\"UTF-8\"?>" << endl
    << "<lib:catalog xmlns:lib=\"http://www.codesynthesis.com/library\"" << endl
    << "  xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"" << endl
    << "  xsi:schemaLocation=\"http://www.codesynthesis.com/library "
    << "library.xsd\">" << endl;


With namespaces streaming becomes a bit tricky.


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/20060922/ab979c0b/attachment.pgp
From raulh39 at tid.es  Thu Sep 28 05:46:35 2006
From: raulh39 at tid.es (Raul Huertas)
Date: Sun Oct 11 15:33:49 2009
Subject: [xsd-users] How to validate XML using a in-memory schema
Message-ID: <451B99FB.5020608@tid.es>

Hello list!

In the "C++/Tree Mapping FAQ" it is explained how to specify locations 
of schemas other than in an instance document, in order to validate 
incoming XML.

Basically, you have to:
    props.no_namespace_schema_location 
("file:///absolute/path/to/schema.xsd")

I don't feel comfortable with this way of doing things because there is 
no runtime way to verify that the file "/absolute/path/to/schema.xsd" is 
the same file that was used to generate C++ code with the xsd tool, is it?

Can I have the schema loaded in memory, in a std::string for example, 
and then use this string to validate XML?
Like:
    std::string myXsd ="<xs:schema ....>..."
    props.no_namespace_schema_location.use (myXsd);

Or, better than that, can the xsd tool save the schema in the generated 
C++ code and then use it to validate XML?

Thanks and Regards,
Raul.


From boris at codesynthesis.com  Thu Sep 28 07:54:22 2006
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:49 2009
Subject: [xsd-users] How to validate XML using a in-memory schema
In-Reply-To: <451B99FB.5020608@tid.es>
References: <451B99FB.5020608@tid.es>
Message-ID: <20060928115422.GC4674@karelia>

Hi Raul,

Raul Huertas <raulh39@tid.es> writes:

> I don't feel comfortable with this way of doing things because there is
> no runtime way to verify that the file "/absolute/path/to/schema.xsd" is
> the same file that was used to generate C++ code with the xsd tool, is it?

No there is no automatic way do do this. Of course you could always compute
a hash sum of the schema file and compare it with the one embedded into the
application to detect the schema/generated code mismatch. This will require
some manual coding, however.


> Can I have the schema loaded in memory, in a std::string for example,
> and then use this string to validate XML?
> Like:
>    std::string myXsd ="<xs:schema ....>..."
>    props.no_namespace_schema_location.use (myXsd);

There is no built-in way but you can achieve this if you are willing
to perform the XML-to-DOM stage yourself. At the same time you can also
cache the schema so that if you parse multiple instance documents the
schema is read and parsed only once.

First check the "How do I parse an XML instance to a Xerces-C++ DOM
document?" question on the C++/Tree Wiki FAQ[1]; it has the code that
does the XML to DOM parsing. You will need to add the following
includes at the beginning:


#include <xercesc/framework/MemBufInputSource.hpp>
#include <xsd/cxx/xml/string.hxx>


And the following code after the "Enable/Disable validation" lines:


std::string my_xsd ="<xs:schema ....>...";
MemBufInputSource mis (my_xsd.c_str (), my_xsd.size (), "/schema.xsd");
Wrapper4InputSource wmis (mis, false);

parser->loadGrammar (wmis, Grammar::SchemaGrammarType, true);
parser->setFeature (XMLUni::fgXercesUseCachedGrammarInParse, true);

parser->setProperty (
  XMLUni::fgXercesSchemaExternalNoNameSpaceSchemaLocation,
  const_cast<void*> (xml::string ("file:///schema.xsd").c_str ()));


Note that the "/schema.xsd" file does not have to exist since it will
be resolved from the cache. I haven't actually tested this code so let
me know whether it works or not ;-).

Once you obtain the DOM document simply invoke the generated parsing
function as you would do on a file name or an std::istream instance.

There is also a nice article[2] on IBM DevWorks if you want more
information on schema caching in Xerces-C++.

> Or, better than that, can the xsd tool save the schema in the generated
> C++ code and then use it to validate XML?

We actually thought about this feature. The problem is that it does not
scale to the case where you have included/imported schemas.


[1] http://wiki.codesynthesis.com/Tree/FAQ
[2] 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/20060928/d641b19b/attachment.pgp
From shpatric at vt.edu  Thu Sep 28 11:10:52 2006
From: shpatric at vt.edu (Patrick Shinpaugh)
Date: Sun Oct 11 15:33:49 2009
Subject: [xsd-users] Issue with includes
Message-ID: <1159456252.2946.14.camel@pbslinux01>

Hi,
I am trying to use xsd to create data binding for the x3d schema
( http://www.web3d.org/x3d/specifications/ ) - the 3 .xsd files. I have
validated the schema using the w3c validator which gives the warnings
about anyType. As such, it appears that your program handles includes
differently than perhaps it should - validating each file separately
instead of as a whole.

Below is the output I get. If I remove the includes then the data
binding will succeed (without the extensions which we also need) and the
anyType variables are handled nicely.

Is there an option to change the way includes are handled?

Any help is appreciated.

Thanks
Pat


[xml-schema-dtd]$ /usr/local/xsd/bin/xsd cxx-tree --morph-anonymous
x3d-3.0.xsd
/home/patrick/projects/x3dosg/xml-schema-dtd/x3d-3.0-Web3dExtensionsPublic.xsd:62:41: error: Type not found in :IS
/home/patrick/projects/x3dosg/xml-schema-dtd/x3d-3.0-Web3dExtensionsPublic.xsd:62:41: error: Ref element IS not found in the Schema
/home/patrick/projects/x3dosg/xml-schema-dtd/x3d-3.0-Web3dExtensionsPublic.xsd:64:40: error: Type not found in :MetadataDouble
/home/patrick/projects/x3dosg/xml-schema-dtd/x3d-3.0-Web3dExtensionsPublic.xsd:64:40: error: Ref element MetadataDouble not found in the Schema
/home/patrick/projects/x3dosg/xml-schema-dtd/x3d-3.0-Web3dExtensionsPublic.xsd:65:39: error: Type not found in :MetadataFloat
/home/patrick/projects/x3dosg/xml-schema-dtd/x3d-3.0-Web3dExtensionsPublic.xsd:65:39: error: Ref element MetadataFloat not found in the Schema
/home/patrick/projects/x3dosg/xml-schema-dtd/x3d-3.0-Web3dExtensionsPublic.xsd:66:41: error: Type not found in :MetadataInteger
/home/patrick/projects/x3dosg/xml-schema-dtd/x3d-3.0-Web3dExtensionsPublic.xsd:66:41: error: Ref element MetadataInteger not found in the Schema
/home/patrick/projects/x3dosg/xml-schema-dtd/x3d-3.0-Web3dExtensionsPublic.xsd:67:37: error: Type not found in :MetadataSet
/home/patrick/projects/x3dosg/xml-schema-dtd/x3d-3.0-Web3dExtensionsPublic.xsd:67:37: error: Ref element MetadataSet not found in the Schema
/home/patrick/projects/x3dosg/xml-schema-dtd/x3d-3.0-Web3dExtensionsPublic.xsd:68:40: error: Type not found in :MetadataString
/home/patrick/projects/x3dosg/xml-schema-dtd/x3d-3.0-Web3dExtensionsPublic.xsd:68:40: error: Ref element MetadataString not found in the Schema
/home/patrick/projects/x3dosg/xml-schema-dtd/x3d-3.0-Web3dExtensionsPublic.xsd:75:59: error: SimpleType (:SFInt32) for attribute: numberOfDivisions not found
/home/patrick/projects/x3dosg/xml-schema-dtd/x3d-3.0-Web3dExtensionsPublic.xsd:76:53: error: SimpleType (:MFFloat) for attribute: vertexRound not found
/home/patrick/projects/x3dosg/xml-schema-dtd/x3d-3.0-Web3dExtensionsPublic.xsd:77:61: error: SimpleType (:MFInt32) for attribute: edgeBeginCoordIndex not found
/home/patrick/projects/x3dosg/xml-schema-dtd/x3d-3.0-Web3dExtensionsPublic.xsd:78:59: error: SimpleType (:MFInt32) for attribute: edgeEndCoordIndex not found
/home/patrick/projects/x3dosg/xml-schema-dtd/x3d-3.0-Web3dExtensionsPublic.xsd:79:51: error: SimpleType (:MFFloat) for attribute: edgeRound not found
/home/patrick/projects/x3dosg/xml-schema-dtd/x3d-3.0-Web3dExtensionsPublic.xsd:80:57: error: SimpleType (:MFVec3f) for attribute: edgeBeginVector not found
/home/patrick/projects/x3dosg/xml-schema-dtd/x3d-3.0-Web3dExtensionsPublic.xsd:81:55: error: SimpleType (:MFVec3f) for attribute: edgeEndVector not found
/home/patrick/projects/x3dosg/xml-schema-dtd/x3d-3.0-Web3dExtensionsPublic.xsd:82:56: error: SimpleType (:MFInt32) for attribute: faceCoordIndex not found
/home/patrick/projects/x3dosg/xml-schema-dtd/x3d-3.0-Web3dExtensionsPublic.xsd:83:59: error: SimpleType (:MFInt32) for attribute: faceTexCoordIndex not found
/home/patrick/projects/x3dosg/xml-schema-dtd/x3d-3.0-Web3dExtensionsPublic.xsd:84:50: error: SimpleType (:MFBool) for attribute: faceEmpty not found
/home/patrick/projects/x3dosg/xml-schema-dtd/x3d-3.0-Web3dExtensionsPublic.xsd:85:51: error: SimpleType (:MFBool) for attribute: faceHidden not found
x3d-3.0.xsd:5805:41: warning: element 'GeoCoordinate' is implicitly of
anyType
x3d-3.0.xsd:5805:41: info: did you forget to specify 'type' attribute?
x3d-3.0.xsd:5806:44: warning: element 'GeoElevationGrid' is implicitly
of anyType
x3d-3.0.xsd:5806:44: info: did you forget to specify 'type' attribute?
x3d-3.0.xsd:5807:39: warning: element 'GeoLocation' is implicitly of
anyType
x3d-3.0.xsd:5807:39: info: did you forget to specify 'type' attribute?
x3d-3.0.xsd:5808:37: warning: element 'GeoOrigin' is implicitly of
anyType
x3d-3.0.xsd:5808:37: info: did you forget to specify 'type' attribute?
x3d-3.0.xsd:5809:34: warning: element 'GeoLOD' is implicitly of anyType
x3d-3.0.xsd:5809:34: info: did you forget to specify 'type' attribute?
x3d-3.0.xsd:5811:51: warning: element 'GeoPositionInterpolator' is
implicitly of anyType
x3d-3.0.xsd:5811:51: info: did you forget to specify 'type' attribute?
x3d-3.0.xsd:5812:42: warning: element 'GeoTouchSensor' is implicitly of
anyType
x3d-3.0.xsd:5812:42: info: did you forget to specify 'type' attribute?
x3d-3.0.xsd:5813:40: warning: element 'GeoViewpoint' is implicitly of
anyType
x3d-3.0.xsd:5813:40: info: did you forget to specify 'type' attribute?
x3d-3.0.xsd:5814:41: warning: element 'ProtoInstance' is implicitly of
anyType
x3d-3.0.xsd:5814:41: info: did you forget to specify 'type' attribute?



From boris at codesynthesis.com  Thu Sep 28 13:19:04 2006
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:49 2009
Subject: [xsd-users] Issue with includes
In-Reply-To: <1159456252.2946.14.camel@pbslinux01>
References: <1159456252.2946.14.camel@pbslinux01>
Message-ID: <20060928171904.GA5754@karelia>

Hi Patrick,

Patrick Shinpaugh <shpatric@vt.edu> writes:

> I am trying to use xsd to create data binding for the x3d schema
> ( http://www.web3d.org/x3d/specifications/ ) - the 3 .xsd files. I have
> validated the schema using the w3c validator which gives the warnings
> about anyType.

I downloaded the schemas and tried to compile x3d-3.0.xsd. I got the
following error:

error: Complex type 'X3DAppearanceNode' violates the Unique Particle
Attribution rule in its components 'ProtoInstance' and 'ProtoInstance'

Did you manage to resolve this?


> As such, it appears that your program handles includes
> differently than perhaps it should - validating each file separately
> instead of as a whole.

Right. XSD tries to preserve the modularity of your schemas in the
generated code by mapping xsd:includes (and xsd:imports) to the C
preprocessor #include directives. As a result of this mapping, XSD
requires that the included schema files be self-sufficient which is
not required by the XML Schema spec as you correctly pointed out.
This is the first real-world schema where we run into this issue.


> Below is the output I get. If I remove the includes then the data
> binding will succeed (without the extensions which we also need) and
> the anyType variables are handled nicely.
>
> Is there an option to change the way includes are handled?

There is no such option at the moment. One way to address this would
be to provide an option to generate code for included schemas inline
instead of generating #include directives. We may implement this
option in the future versions of XSD.

Meantime I can suggest a couple of workarounds:

1. XSD can handle cyclic inclusion if the types in the two schemas
   do not inherit from each other (e.g., type D from schema d.xsd
   inherits from type B from schema b.xsd and both b.xsd and d.xsd
   include each other). So the first thing to try it to xsd:include
   x3d-3.0.xsd in x3d-3.0-Web3dExtensionsPrivate.xsd  and/or
   x3d-3.0-Web3dExtensionsPublic.xsd and see of the generated code
   compiles. I do not know what you have in your extension schemas
   so I cannot say whether this will work or not.

2. The second approach is to still add inclusion of x3d-3.0.xsd in
   x3d-3.0-Web3dExtensionsPrivate.xsd  and/or
   x3d-3.0-Web3dExtensionsPublic.xsd but break the cycle by removing
   inclusions from x3d-3.0.xsd. You can also rename the modified
   x3d-3.0.xsd to something like x3d-3.0-base.xsd and create a new
   x3d-3.0.xsd which will include all three other schemas. In other
   words, you include graph will look like this:

   x3d-3.0-base.xsd
   x3d-3.0-Web3dExtensionsPublic.xsd includes x3d-3.0-base.xsd
   x3d-3.0-Web3dExtensionsPrivate.xsd includes x3d-3.0-base.xsd
   x3d-3.0.xsd: includes x3d-3.0-base.xsd, x3d-3.0-Web3dExtensionsPublic.xsd,
     and x3d-3.0-Web3dExtensionsPrivate.xsd

   This method will work no matter what you have in your schemas and will
   result in the schema equivalent to the original (e.g., it will validate
   exactly the same set of documents).

Please let me know if this works for you.


-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/20060928/5189c0f4/attachment.pgp
From pshinpaugh at vt.edu  Thu Sep 28 18:15:04 2006
From: pshinpaugh at vt.edu (Patrick Shinpaugh)
Date: Sun Oct 11 15:33:49 2009
Subject: [xsd-users] Issue with includes
In-Reply-To: <20060928171904.GA5754@karelia>
References: <1159456252.2946.14.camel@pbslinux01>
	<20060928171904.GA5754@karelia>
Message-ID: <1159481704.10345.346.camel@wakko.sv.vt.edu>

Hi Boris,
You must have downloaded the zip archive - unfortunately it is from 2004
whereas the individual .xsd files on that page are from early 2006.

I will give the workarounds you suggested a try when I get a chance
sometime next week. They do sound promising - I'll let you know.

Thanks,
Patrick


On Thu, 2006-09-28 at 13:19, Boris Kolpackov wrote:
> Hi Patrick,
> 
> Patrick Shinpaugh <shpatric@vt.edu> writes:
> 
> > I am trying to use xsd to create data binding for the x3d schema
> > ( http://www.web3d.org/x3d/specifications/ ) - the 3 .xsd files. I have
> > validated the schema using the w3c validator which gives the warnings
> > about anyType.
> 
> I downloaded the schemas and tried to compile x3d-3.0.xsd. I got the
> following error:
> 
> error: Complex type 'X3DAppearanceNode' violates the Unique Particle
> Attribution rule in its components 'ProtoInstance' and 'ProtoInstance'
> 
> Did you manage to resolve this?
> 
> 
> > As such, it appears that your program handles includes
> > differently than perhaps it should - validating each file separately
> > instead of as a whole.
> 
> Right. XSD tries to preserve the modularity of your schemas in the
> generated code by mapping xsd:includes (and xsd:imports) to the C
> preprocessor #include directives. As a result of this mapping, XSD
> requires that the included schema files be self-sufficient which is
> not required by the XML Schema spec as you correctly pointed out.
> This is the first real-world schema where we run into this issue.
> 
> 
> > Below is the output I get. If I remove the includes then the data
> > binding will succeed (without the extensions which we also need) and
> > the anyType variables are handled nicely.
> >
> > Is there an option to change the way includes are handled?
> 
> There is no such option at the moment. One way to address this would
> be to provide an option to generate code for included schemas inline
> instead of generating #include directives. We may implement this
> option in the future versions of XSD.
> 
> Meantime I can suggest a couple of workarounds:
> 
> 1. XSD can handle cyclic inclusion if the types in the two schemas
>    do not inherit from each other (e.g., type D from schema d.xsd
>    inherits from type B from schema b.xsd and both b.xsd and d.xsd
>    include each other). So the first thing to try it to xsd:include
>    x3d-3.0.xsd in x3d-3.0-Web3dExtensionsPrivate.xsd  and/or
>    x3d-3.0-Web3dExtensionsPublic.xsd and see of the generated code
>    compiles. I do not know what you have in your extension schemas
>    so I cannot say whether this will work or not.
> 
> 2. The second approach is to still add inclusion of x3d-3.0.xsd in
>    x3d-3.0-Web3dExtensionsPrivate.xsd  and/or
>    x3d-3.0-Web3dExtensionsPublic.xsd but break the cycle by removing
>    inclusions from x3d-3.0.xsd. You can also rename the modified
>    x3d-3.0.xsd to something like x3d-3.0-base.xsd and create a new
>    x3d-3.0.xsd which will include all three other schemas. In other
>    words, you include graph will look like this:
> 
>    x3d-3.0-base.xsd
>    x3d-3.0-Web3dExtensionsPublic.xsd includes x3d-3.0-base.xsd
>    x3d-3.0-Web3dExtensionsPrivate.xsd includes x3d-3.0-base.xsd
>    x3d-3.0.xsd: includes x3d-3.0-base.xsd, x3d-3.0-Web3dExtensionsPublic.xsd,
>      and x3d-3.0-Web3dExtensionsPrivate.xsd
> 
>    This method will work no matter what you have in your schemas and will
>    result in the schema equivalent to the original (e.g., it will validate
>    exactly the same set of documents).
> 
> Please let me know if this works for you.
> 
> 
> -boris
> 
> 
> ______________________________________________________________________
> _______________________________________________
> xsd-users mailing list
> xsd-users@codesynthesis.com
> http://codesynthesis.com/mailman/listinfo/xsd-users
-- 
Patrick Shinpaugh
Virginia Tech
UVAG System Administrator/Programmer
540-231-2054


From raulh39 at tid.es  Fri Sep 29 05:00:24 2006
From: raulh39 at tid.es (Raul Huertas)
Date: Sun Oct 11 15:33:49 2009
Subject: [xsd-users] How to validate XML using a in-memory schema
In-Reply-To: <20060928115422.GC4674@karelia>
References: <451B99FB.5020608@tid.es> <20060928115422.GC4674@karelia>
Message-ID: <451CE0A8.9010204@tid.es>


   It works!
   However, I need to make some minor changes to your suggestions:

     First check the "How do I parse an XML instance to a Xerces-C++ DOM
document?" question on the C++/Tree Wiki FAQ[1]; it has the code that
does the XML to DOM parsing. You will need to add the following
includes at the beginning:


#include <xercesc/framework/MemBufInputSource.hpp>
#include <xsd/cxx/xml/string.hxx>

  

also:
#include <xercesc/validators/common/Grammar.hpp>

And the following code after the "Enable/Disable validation" lines:

std::string my_xsd ="<xs:schema ....>...";
  

    const XMLByte*bytes=reinterpret_cast<const XMLByte*>(my_xsd.c_str());
    MemBufInputSource mis (bytes, my_xsd.size (), "/schema.xsd");
    Wrapper4InputSource wmis (&mis, false);
    
    parser->loadGrammar (wmis, Grammar::SchemaGrammarType, true);
    parser->setFeature (XMLUni::fgXercesUseCachedGrammarInParse, true);
    
    void* id=(void*)([1]"file:///schema.xsd");
    parser->setProperty (
        XMLUni::fgXercesSchemaExternalNoNameSpaceSchemaLocation,
        id
    );

 I haven't actually tested this code so let
me know whether it works or not ;-).


   Yes, it works, thank you very much.
   Regards,
   Raul.

References

   1. file://localhost/schema.xsd

From boris at codesynthesis.com  Fri Sep 29 07:13:01 2006
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:49 2009
Subject: [xsd-users] Issue with includes
In-Reply-To: <1159481704.10345.346.camel@wakko.sv.vt.edu>
References: <1159456252.2946.14.camel@pbslinux01>
	<20060928171904.GA5754@karelia>
	<1159481704.10345.346.camel@wakko.sv.vt.edu>
Message-ID: <20060929111301.GA7286@karelia>

Hi Patrick,

Patrick Shinpaugh <pshinpaugh@vt.edu> writes:

> Hi Boris,
> You must have downloaded the zip archive - unfortunately it is from 2004
> whereas the individual .xsd files on that page are from early 2006.

Ah, who would have imagined they were different ;-). I downloaded the
individual files and could reproduce the problem you reported. I tried
the workarounds I suggested in my previous email. The first approach
(including x3d-3.0.xsd in x3d-3.0-Web3dExtensionsPublic.xsd) works
except for two things:

1. There was an obscure bug in the anonymous type morphing logic that
   only manifested itself when you have such a cyclic inclusion. I've
   fixed this bug for the next version.

2. The schema uses some default values that include '"' characters.
   These were not properly escaped when used in the generated code so
   the resulting code would not compile. I've fixed this as well.

Otherwise I could compile the schemas and the generated code without
any problems. I can build you a pre-release binary of XSD - just let
me know which platform(s) and package format(s) you need.


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/20060929/6dec8c36/attachment.pgp
From boris at codesynthesis.com  Fri Sep 29 07:47:46 2006
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:49 2009
Subject: [xsd-users] How to validate XML using a in-memory schema
In-Reply-To: <451CE0A8.9010204@tid.es>
References: <451B99FB.5020608@tid.es> <20060928115422.GC4674@karelia>
	<451CE0A8.9010204@tid.es>
Message-ID: <20060929114746.GB7286@karelia>

Hi Raul,

Raul Huertas <raulh39@tid.es> writes:

>    It works!

Great!


>      const XMLByte*bytes=reinterpret_cast<const XMLByte*>(my_xsd.c_str());
>      MemBufInputSource mis (bytes, my_xsd.size (), "/schema.xsd");
>      Wrapper4InputSource wmis (&mis, false);
>
>      parser->loadGrammar (wmis, Grammar::SchemaGrammarType, true);
>      parser->setFeature (XMLUni::fgXercesUseCachedGrammarInParse, true);
>
>      void* id=(void*)("file:///schema.xsd");
>      parser->setProperty (
>          XMLUni::fgXercesSchemaExternalNoNameSpaceSchemaLocation,
>          id
>      );

I don't think this is the right way to set the property because Xerces-C++
expects the string to be XMLCh* (2 bytes per code point) while you are
passing char* (1 byte per code point). I think the right way to do it would
be:


xml::string id ("file:///schema.xsd");
const void* vid (id.c_str ());

parser->setProperty (
  XMLUni::fgXercesSchemaExternalNoNameSpaceSchemaLocation,
  const_cast<void*> (vid));

Or, without named temporaries:

parser->setProperty (
  XMLUni::fgXercesSchemaExternalNoNameSpaceSchemaLocation,
  const_cast<void*> (
    static_cast<const void*> (
      xml::string ("file:///schema.xsd").c_str ())));


xml::string is a simple string type for Xerces-C++'s XMLCh.

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/20060929/6f18b3d0/attachment.pgp
From boris at codesynthesis.com  Fri Sep 29 08:43:13 2006
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:49 2009
Subject: [xsd-users] Re: Reg: Problem with xsd tool while using unicode...
In-Reply-To: <OF3CA1D32E.862B6522-ON652571F5.001D1A3C-652571F5.001EFB01@tcs.com>
References: <OF3CA1D32E.862B6522-ON652571F5.001D1A3C-652571F5.001EFB01@tcs.com>
Message-ID: <20060929124313.GD7286@karelia>

Hi Subhash,

In the future please send technical questions like this to the
xsd-users mailing list (which I've CC'ed) instead of to me directly.
This way a) other developers who may have experienced a similar
problem can provide you with a solution b) questions and answers
will be archived and available to others with similar problems.


subhash.dixit@tcs.com <subhash.dixit@tcs.com> writes:

> Hi Boris.
> I am using XSD tool for xml parsing on solaris.It is working fine with
> utf-8 encoding. It really helped us to develop our product. Now i want to
> integrate it with unicode. But I am not quite sure how to go for it. I
> want to know whether the same xsd tool will work for utf-16 encoding or
> not .
> I  changed the encoding variable to utf-16 form utf-8 in xsd file
> manually. And then tried to create the .cxx and .hxx file.
> It created the file with the warning -
>                   "CustDetails.xsd:1:41: warning: Encoding (utf-16, from
> XMLDecl or manually set) contradicts the auto-sensed encoding, ignoring
> it"
> After that when i tried to create the auto pointer then it gave
> compilation error saying that it is not accessible from main.
>  Can you please help me in this regard. Is there any solution for this
> problem. Does xsd supports unicode or utf-16.
> I m sending you the xsd file.

I think you are confusing three things here which are not related in the
way you seem to expect them to:

1. Encoding used in XML instance documents

   This is specified in the "XML declaration" at the beginning of
   XML documents, e.g.:

   <?xml version="1.0" encoding="UTF-16" ?>

   XSD can parse XML documents in a variety of encodings, including
   ASCII, UTF-8, UTF-16 and UTF-32, *regardless* (and this is important)
   of the encodings used for (2) and (3).


2. Encoding used in your XML Schema file

   This is specified in your .xsd files in the XML declaration (since
   .xsd file is an XML file) and prescribes the encoding of your
   XML Schema document itself. Note that this encoding does not affect
   any of the (1) and (3) as you seem to assume.


3. Encoding used in your application

   This is specified via the --char-type option when compiling your
   schemas with XSD and, in some cases, by setting the appropriate
   default locale in your application.

   The two supported values for this option are 'char' and 'wchar_t'.
   The encoding for 'char' can be any 8-bit encoding such as UTF-8.
   For 'wchar_t' it is a little bit more complicated. Different
   platforms have different wchar_t sizes: some (e.g., VC++ on Windows)
   have 16 bit and others (e.g, most UNIX C++ compilers) have 32 bit.
   Where wchar_t is 16 bit wide it makes sense to use UTF-16. On systems
   with 32 bits you can choose to use either UTF-16 or UTF-32 (also
   known as UCS-4). If you choose to use UTF-16 then two bytes of
   every character will be unused. The nice thing about UTF-32/UCS-4
   is that it is a fixed-width encoding, i.e., each code point occupies
   exactly one 4-byte element which is not the case with UTF-8 or UTF-16.


Now, let's consider an examples. It does not really matter which encoding
we choose for (2) so we will ignore it here (I suggest that you stick to
ASCII or UTF-8).

Let's assume we've compiled our schemas with '--char-type char' and set
the default locale in our application to UTF-8:

   #include <locale.h>

   int
   main (int argc, char* argv[])
   {
     setlocale (LC_CTYPE, "UTF-8");

     ...
   }

If we feed our application a UTF-16 encoded XML document then all the
content will be transcoded from UTF-16 to UTF-8 and our application
will be presented with the data in UTF-8. The same will happen for
any other encoding that an XML instance may use. In other words,
no matter what encoding an XML instance has, it will be transcoded
to the application-local encoding (UTF-8 in this example).

It is also possible to write out XML documents in a different encoding
compared to the the application-local. For this, all serialization
functions have the 'encoding' argument. To put this all together, as
an example, you can read a UTF-16 XML document, manipulate it in UTF-8
in your application and write it out in UTF-32.

hth,
-boris


>
> <?xml version="1.0" encoding="utf-16" ?>
> <xs:schema id="CustInfo"  elementFormDefault="qualified"
> xmlns="http://tempuri.org/CustInfo.xsd" xmlns:mstns="http://tempuri.
> org/ CustInfo.xsd" xmlns:xs="http://www.w3.org/2001/XMLSchema">
>
>         <xs:element name="custEntry" >
>         <xs:complexType>
>         <xs:sequence>
>                 <xs:element name="msgID" type="xs:string" />
>                 <xs:element name="custId" type="xs:string"/>
>
>                 <xs:element name="custDetails" >
>                 <xs:complexType>
>                 <xs:sequence>
>                         <xs:element name="custFname" type="xs:string" />
>                         <xs:element name="custLname" type="xs:string" />
>                         <xs:element name="gender" type="xs:string"
> minOccurs="0"/>
>                         <xs:element name="addSeqNum" type="xs:string" />
>                         <xs:element name="country" type="xs:string" />
>                         <xs:element name="idSeqNum" type="xs:string" />
>                         <xs:element name="idNum" type="xs:string" />
>                         <xs:element name="idIssPlace" type="xs:string" />
>                 </xs:sequence>
>                 </xs:complexType>
>                 </xs:element>
>
>         </xs:sequence>
>         </xs:complexType>
>         </xs:element>
>
> </xs:schema>
-------------- 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/20060929/4846e6cd/attachment.pgp
From subhash.dixit at tcs.com  Sat Sep 30 04:42:43 2006
From: subhash.dixit at tcs.com (subhash.dixit@tcs.com)
Date: Sun Oct 11 15:33:49 2009
Subject: [xsd-users] (no subject)
Message-ID: <OF626D83BC.89FFB1FB-ON652571F9.002FCCB5-652571F9.002FDBE8@tcs.com>

Hi all.
I am using unicode for xml parsing. I am trying to create Input 
Source with UChar data. Is it valid to create MemBufInputSource with 
UChar data.
Becouse I am getting "instance document is not valid" error. Is 
there any other way to create MemBufInputSource with UChar data as 
MemBufInputSource accepts const XMLByte data type.

Any help regarding this.
Plz reply soon as this is very urgent for me.
Thanking you in advance


Subhash Chandra Dixit
Tata Consultancy Services Limited
Mailto: subhash.dixit@tcs.com
Website: http://www.tcs.com
=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you



From boris at codesynthesis.com  Sat Sep 30 12:01:31 2006
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:49 2009
Subject: [xsd-users] (no subject)
In-Reply-To: <OF626D83BC.89FFB1FB-ON652571F9.002FCCB5-652571F9.002FDBE8@tcs.com>
References: <OF626D83BC.89FFB1FB-ON652571F9.002FCCB5-652571F9.002FDBE8@tcs.com>
Message-ID: <20060930160131.GA20122@karelia>

Hi Subhash,

subhash.dixit@tcs.com <subhash.dixit@tcs.com> writes:

> I am using unicode for xml parsing. I am trying to create Input
> Source with UChar data. Is it valid to create MemBufInputSource with
> UChar data.
> Becouse I am getting "instance document is not valid" error. Is
> there any other way to create MemBufInputSource with UChar data as
> MemBufInputSource accepts const XMLByte data type.

Note that there are lots of libraries that define UChar - we have
no idea which one you are using. From our previous (private)
correspondence I can guess that you are using ICU. ICU UChar
represents a UTF-16 code point and is 16 bits wide. Since
MemBufInputSource operates on bytes you will need to multiply the
length of your UChar string by two in order to get the right size
in bytes:

UChar* ustr = ...
unsigned long ulen = ...

MemBufInputSource is (reinterpret_cast<XMLByte*> (ustr), ulen * 2);

You may also have to override the default encoding which is obtained
from the XML document by calling the setEncoding function on
MemBufInputSource:

is.setEncoding (XMLUni::fgUTF16BEncodingString); // On a big-endian machine
is.setEncoding (XMLUni::fgUTF16LEncodingString); // On a little-endian machine


> Plz reply soon as this is very urgent for me.

You may want to consider getting a priority support contract[1] if you
require guaranteed response time.


[1] http://www.codesynthesis.com/support/

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/20060930/46b28699/attachment.pgp