From boris at codesynthesis.com  Mon Jan  1 09:51:29 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:51 2009
Subject: [xsd-users] Re: Serialisation issue.
In-Reply-To: <BCDDAD85D426814E9994B7A29899D03F2B5200@desmdswms202.des.grplnk.net>
References: <20061222101308.GC20058@karelia>
	<BCDDAD85D426814E9994B7A29899D03F2B5200@desmdswms202.des.grplnk.net>
Message-ID: <20070101145129.GA2538@karelia>

Hi David,


Moss, David R (SELEX Comms) (UK Christchurch) <david.r.moss@selex-comm.com> writes:

> I'm also using 2.7.0.
>
> With the attached files, test-users-2.xml doesn't load:
>
> // Loads.
> auto_ptr<class UserDatabase_t> db( UserDatabase( "test-users.xml" ) );
>
> // Exception thrown.
> auto_ptr<class UserDatabase_t> db2( UserDatabase( "test-users-2.xml" )
> );

I now can reproduce the problem too. I did some debugging and here is
what I've come up with. XML Schema import directives and schemaLocation
attributes "hint" the schema processor which schema files "cover" which
namespace. As a result most (all?) schema processors use namespace
URIs as keys when they try to determine whether a grammar for a
particular namespace has already been loaded.

Here is what happens in your case when noNamespaceSchemaLocation comes
first (as in test-users-2.xml). The parser loads derived-user-config.xsd
which imports test-user-config.xsd for namespace http://www.dave.com/Base.
Then the parser moves on to schemaLocation attribute which specifies
test-users.xsd for namespace http://www.dave.com/Base. Before loading
test-users.xsd, the parser checks whether there is already grammar for
the http://www.dave.com/Base namespace. Since we've already "covered"
http://www.dave.com/Base with test-user-config.xsd, the parser skips
loading test-users.xsd. And everything goes downhill from here.

I tend to think it is a general XML Schema design flaw (or limitation)
rather than a bug in Xerces-C++. The idea is that you need to always
specify a complete, top-level schema file for a namespace in import
declarations and schemaLocation attributes. In your case that would
mean to import test-users.xsd instead of test-user-config.xsd in
derived-user-config.xsd. There are also a couple of alternative
solutions:

1. Use different namespaces for test-users.xsd and test-user-config.xsd.

2. Instead of specifying schemas in instance documents, you can
   programmatically load them into Xerces-C++ grammar cache. This way
   you can make sure that you load schemas in the proper order (i.e.,
   first test-users.xsd, then derived-user-config.xsd). For more
   information on how to do this see the following resources:

   http://www-128.ibm.com/developerworks/webservices/library/x-xsdxerc.html
   http://wiki.codesynthesis.com/Tree/FAQ


> (As an aside, the first shouldn't load either as Number should be
> unique. I'm assuming this is due to xpath="TestUserConfig" not allowing
> for substitution groups.)

Since XML Schema identity constraints are based on XPath and XPath operates
in terms of elements and attributes (instead of types), identity constraints
do not work very well with substitution groups where you change element
names (they work ok with xsi:type, since the element name stays the same).

The only way to make it work with substitution groups is to list all
possible substitutions in the selector:

xpath="b:TestUserConfig|DerivedUserConfig"

(Note, you need to use xpath="b:TestUserConfig" since TestUserConfig is a
qualified element.)

This is not very flexible since you have to hard-code all possible
substitutions. I think the best solution in this case is to scrap XML
Schema identity constraints altogether and implement the check in the
code:

const UserDatabase_t& db = ...
std::set<xml_schema::string> ids;

for (UserDatabase_t::TestUserConfig::const_iterator
     i (db.TestUserConfig ().begin ());
     i != db.TestUserConfig ().end ();
     ++i)
{
  if (ids.find (i->Number ()) != ids.end ())
  {
    // Identity constraint violation.
  }

  ids.insert (i->Number ());
}


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/20070101/2b59a6e5/attachment.pgp
From david.r.moss at selex-comm.com  Wed Jan  3 11:22:14 2007
From: david.r.moss at selex-comm.com (Moss, David R (SELEX Comms) (UK Christchurch))
Date: Sun Oct 11 15:33:51 2009
Subject: [xsd-users] RE: Serialisation issue.
In-Reply-To: <20070101145129.GA2538@karelia>
Message-ID: <BCDDAD85D426814E9994B7A29899D03F2B5206@desmdswms202.des.grplnk.net>


Boris,

Comments below.

Cheers
Dave.

Dave Moss
SELEX Communications
Grange Road
Christchurch 
Dorset  BH23 4JE
United Kingdom
Tel: + 44 (0) 1202 404841
Email: david.r.moss@selex-comm.com

> I tend to think it is a general XML Schema design flaw (or limitation)
> rather than a bug in Xerces-C++. The idea is that you need to always
> specify a complete, top-level schema file for a namespace in import
> declarations and schemaLocation attributes. In your case that would
> mean to import test-users.xsd instead of test-user-config.xsd in
> derived-user-config.xsd. There are also a couple of alternative
> solutions:
> 
> 1. Use different namespaces for test-users.xsd and
test-user-config.xsd.
> 
> 2. Instead of specifying schemas in instance documents, you can
>    programmatically load them into Xerces-C++ grammar cache. This way
>    you can make sure that you load schemas in the proper order (i.e.,
>    first test-users.xsd, then derived-user-config.xsd). For more
>    information on how to do this see the following resources:
> 
>    http://www-128.ibm.com/developerworks/webservices/library/x-
> xsdxerc.html
>    http://wiki.codesynthesis.com/Tree/FAQ
> 

[Moss, David R] 

Right. Importing test-users.xsd instead does the job nicely. 

> 
> Since XML Schema identity constraints are based on XPath and XPath
> operates
> in terms of elements and attributes (instead of types), identity
> constraints
> do not work very well with substitution groups where you change
element
> names (they work ok with xsi:type, since the element name stays the
same).
> 
[Moss, David R] 

I thought I'd try again the xsi:type method (see attached files,
ignoring the commented-out bits from the substitution approach), but I'm
getting 'error, unknown element Age' messages when loading the xml
file.... I'm probably suffering from first-day-back stupidity!


> The only way to make it work with substitution groups is to list all
> possible substitutions in the selector:
> 
> xpath="b:TestUserConfig|DerivedUserConfig"
> 
> (Note, you need to use xpath="b:TestUserConfig" since TestUserConfig
is a
> qualified element.)
> 
> This is not very flexible since you have to hard-code all possible
> substitutions. I think the best solution in this case is to scrap XML
> Schema identity constraints altogether and implement the check in the
> code:
> 

[Moss, David R] 

I think I might end up doing this even if the xsi:type approach works as
it's more user-friendly - clients don't have to add
xsi:type="DerivedUserConfig_t" statements to each record in the
database!

Happy New Year :)
 

> hth,
> -boris


********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************
-------------- next part --------------
A non-text attachment was scrubbed...
Name: derived-user-config.xsd
Type: application/octet-stream
Size: 742 bytes
Desc: derived-user-config.xsd
Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070103/52138b22/derived-user-config.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test-user-config.xsd
Type: application/octet-stream
Size: 600 bytes
Desc: test-user-config.xsd
Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070103/52138b22/test-user-config.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test-users.xsd
Type: application/octet-stream
Size: 890 bytes
Desc: test-users.xsd
Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070103/52138b22/test-users.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test-users.xml
Type: text/xml
Size: 745 bytes
Desc: test-users.xml
Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070103/52138b22/test-users.bin
From boris at codesynthesis.com  Thu Jan  4 02:39:00 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:51 2009
Subject: [xsd-users] Re: Serialisation issue.
In-Reply-To: <BCDDAD85D426814E9994B7A29899D03F2B5206@desmdswms202.des.grplnk.net>
References: <20070101145129.GA2538@karelia>
	<BCDDAD85D426814E9994B7A29899D03F2B5206@desmdswms202.des.grplnk.net>
Message-ID: <20070104073900.GA10646@karelia>

Hi David,

> I thought I'd try again the xsi:type method (see attached files,
> ignoring the commented-out bits from the substitution approach), but I'm
> getting 'error, unknown element Age' messages when loading the xml
> file.... I'm probably suffering from first-day-back stupidity!

This seems to be a bug in Xerces-C++. I've reported it to their
bug database:

http://issues.apache.org/jira/browse/XERCESC-1664

Adding a namespace to derived-user-config.xsd makes the error go
away. Generally, I wouldn't recommend mixing schemas with
namespaces and those without since a lot of special cases and
rules arise. Also because most people follow this guideline,
such mixing is not very well tested in schema processors.


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/20070104/10604b4c/attachment.pgp
From david.r.moss at selex-comm.com  Thu Jan  4 04:44:21 2007
From: david.r.moss at selex-comm.com (Moss, David R (SELEX Comms) (UK Christchurch))
Date: Sun Oct 11 15:33:51 2009
Subject: [xsd-users] RE: Serialisation issue.
In-Reply-To: <20070104073900.GA10646@karelia>
Message-ID: <BCDDAD85D426814E9994B7A29899D03F2B5207@desmdswms202.des.grplnk.net>


Boris,

> This seems to be a bug in Xerces-C++. I've reported it to their
> bug database:
> 
[Moss, David R] 
Thanks for doing that.

> Adding a namespace to derived-user-config.xsd makes the error go
> away. Generally, I wouldn't recommend mixing schemas with
> namespaces and those without since a lot of special cases and
> rules arise. 

[Moss, David R] 
You're right, mixing namespaces & no namespaces is causing problems (or
at least making things complicated!) so I'll use a namespace for my
derived schema.

However, having done this, the uniqueness constraint still seems to fail
(that is, allows the xml file to load) which, if I understand you
correctly, should not be the case using xsi:type as I'm always dealing
with 'TestUserConfig Number' in the instance document - see attached
files.


> Also because most people follow this guideline,
> such mixing is not very well tested in schema processors.
 
[Moss, David R] 
Surely finding bugs is a good thing! :)

Cheers,
Dave.

Dave Moss
SELEX Communications
Grange Road
Christchurch 
Dorset  BH23 4JE
United Kingdom
Tel: + 44 (0) 1202 404841
Email: david.r.moss@selex-comm.com


********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test-users.xsd
Type: application/octet-stream
Size: 890 bytes
Desc: test-users.xsd
Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070104/c1fae5ef/test-users.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test-users.xml
Type: text/xml
Size: 823 bytes
Desc: test-users.xml
Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070104/c1fae5ef/test-users.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: derived-user-config.xsd
Type: application/octet-stream
Size: 802 bytes
Desc: derived-user-config.xsd
Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070104/c1fae5ef/derived-user-config.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test-user-config.xsd
Type: application/octet-stream
Size: 616 bytes
Desc: test-user-config.xsd
Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070104/c1fae5ef/test-user-config.obj
From boris at codesynthesis.com  Thu Jan  4 05:06:15 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:51 2009
Subject: [xsd-users] Re: Serialisation issue.
In-Reply-To: <BCDDAD85D426814E9994B7A29899D03F2B5207@desmdswms202.des.grplnk.net>
References: <20070104073900.GA10646@karelia>
	<BCDDAD85D426814E9994B7A29899D03F2B5207@desmdswms202.des.grplnk.net>
Message-ID: <20070104100615.GC10646@karelia>

Hi David,

Moss, David R (SELEX Comms) (UK Christchurch) <david.r.moss@selex-comm.com> writes:


> However, having done this, the uniqueness constraint still seems to fail
> (that is, allows the xml file to load) which, if I understand you
> correctly, should not be the case using xsi:type as I'm always dealing
> with 'TestUserConfig Number' in the instance document - see attached
> files.

You've changed TestUserConfig in UserDatabase_t to be unqualified but
haven't changed xpath="b:TestUserConfig" to reflect this.


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/20070104/f14e821c/attachment.pgp
From marco.fischer at chipvision.com  Thu Jan  4 05:19:06 2007
From: marco.fischer at chipvision.com (Marco Fischer)
Date: Sun Oct 11 15:33:51 2009
Subject: [xsd-users] Memory requirements of the C++/Tree in-memory
	representation
Message-ID: <1167905946.6991.30.camel@wiesel.fauna>

Hi,

does anyone have rough numbers about the relative size of the in-memory
representation of an XML file comparing:

- in-memory representation obtained by reading an XML file through an
xsd generated C++/Tree mapping

vs.

- hand-crafted classes representing the content of the XML file

Suppose I was not so much interested in validation or serialization, but
just in using XML Schema to model application data structures and
benefit from the code generation performed for me by xsd.

How much overhead in memory consumption would I have to expect? Just
roughly, like x1, x2, x10?

Cheers,
Marco


From boris at codesynthesis.com  Thu Jan  4 05:42:19 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:51 2009
Subject: [xsd-users] Memory requirements of the C++/Tree in-memory
	representation
In-Reply-To: <1167905946.6991.30.camel@wiesel.fauna>
References: <1167905946.6991.30.camel@wiesel.fauna>
Message-ID: <20070104104219.GD10646@karelia>

Hi Marco,

Marco Fischer <marco.fischer@chipvision.com> writes:

> does anyone have rough numbers about the relative size of the in-memory
> representation of an XML file comparing:
>
> - in-memory representation obtained by reading an XML file through an
> xsd generated C++/Tree mapping
>
> vs.
>
> - hand-crafted classes representing the content of the XML file
>
>
> How much overhead in memory consumption would I have to expect? Just
> roughly, like x1, x2, x10?

I think you will get pretty much the same memory consumption unless you
exploit some application-specific knowledge in hand-crafted classes
(I can't even think of any non-contrived example, maybe something like
a situation where you have two identical strings in your data model
so you will actually have one string and just reference it from two
different places).

The reason for this being that XSD does all the things that one would
normally do in hand-written code: when you have an int, you will store
it as an int in your classes (even though it is text in XML), but so
does XSD-generated code. Same goes for other types (binary data, enums,
etc.). Other than that I do not see how else the memory footprint can
be different.


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/20070104/663a9d9c/attachment.pgp
From doug.kunzman at sensor.com  Thu Jan  4 11:51:54 2007
From: doug.kunzman at sensor.com (Doug Kunzman)
Date: Sun Oct 11 15:33:51 2009
Subject: [xsd-users] Thread Safety
Message-ID: <000801c73020$a3cff4b0$5bed6bc0@sensor.com>

I was wondering if XSD is thread safe?

Please respond directly to doug.kunzman@sensor.com

Thanks,
Doug Kunzman



From boris at codesynthesis.com  Thu Jan  4 15:25:51 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:51 2009
Subject: [xsd-users] Thread Safety
In-Reply-To: <000801c73020$a3cff4b0$5bed6bc0@sensor.com>
References: <000801c73020$a3cff4b0$5bed6bc0@sensor.com>
Message-ID: <20070104202551.GB13109@karelia>

Hi Doug,

[I only noticed your mailing list post after I have replied
 to your private email. I am posting the same reply to
 xsd-users for others who could be interested.]


Doug Kunzman <doug.kunzman@sensor.com> writes:

> I was wondering if XSD is thread safe?

XSD is thread-safe in the sense that you can use different
instantiations of the generated classes in several threads
simultaneously. This is possible due to the generated code
not relying on any global variables[1].

If you need to share the same object between several threads
then you will need to provide some form of synchronization.
You can use the generated code customization mechanisms to
embed the synchronization primitives into the generated
classes.


[1] When you generate polymorphism-aware code, there are
    global type maps being generated. They are thread-safe
    since they are initialized during program startup and
    are read-only after that.

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/20070104/8ef16386/attachment.pgp
From marco.fischer at chipvision.com  Fri Jan  5 04:54:17 2007
From: marco.fischer at chipvision.com (Marco Fischer)
Date: Sun Oct 11 15:33:51 2009
Subject: [xsd-users] Memory requirements of the C++/Tree in-memory
	representation
In-Reply-To: <20070104104219.GD10646@karelia>
References: <1167905946.6991.30.camel@wiesel.fauna>
	<20070104104219.GD10646@karelia>
Message-ID: <1167990857.6908.13.camel@wiesel.fauna>


> I think you will get pretty much the same memory consumption unless you
> exploit some application-specific knowledge in hand-crafted classes

Fine, that's basically what I expected. I was a bit unsure, because I
thought there might be DOM nodes (or maybe other bookkeeping data)
associated with every instance of a C++/Tree generated class at
run-time.

Does the xsd run-time use DOM nodes when XML is de-serialized and
discard them after instances of the generated classes are built? Or does
it use a SAX like parsing process where the instances of generated
classes are created directly?

Regards,
Marco


From boris at codesynthesis.com  Fri Jan  5 04:54:44 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:51 2009
Subject: [xsd-users] Memory requirements of the C++/Tree in-memory
	representation
In-Reply-To: <1167990857.6908.13.camel@wiesel.fauna>
References: <1167905946.6991.30.camel@wiesel.fauna>
	<20070104104219.GD10646@karelia>
	<1167990857.6908.13.camel@wiesel.fauna>
Message-ID: <20070105095444.GB14525@karelia>

Hi Marco,

Marco Fischer <marco.fischer@chipvision.com> writes:


> Fine, that's basically what I expected. I was a bit unsure, because I
> thought there might be DOM nodes (or maybe other bookkeeping data)
> associated with every instance of a C++/Tree generated class at
> run-time.

By default, after parsing is complete, the DOM document is released.
You can keep the DOM document around (with associations between
C++/Tree and DOM nodes) by passing the xml_schema::flags::keep_dom
flag to one of the parsing functions.


> Does the xsd run-time use DOM nodes when XML is de-serialized and
> discard them after instances of the generated classes are built? Or does
> it use a SAX like parsing process where the instances of generated
> classes are created directly?

It uses DOM during parsing and serialization.


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/20070105/7855e813/attachment.pgp
From johns at lanl.gov  Fri Jan  5 13:14:08 2007
From: johns at lanl.gov (Russell C. Johns)
Date: Sun Oct 11 15:33:51 2009
Subject: [xsd-users] Attribute order on serialization.
Message-ID: <1168020848.10277.24.camel@gladiola.lanl.gov>

Hi-

 I have just created a test program to do a round trip of an xml file.
using the cxx-tree option of xsd. i.e. XML -> C++ -> XML.  manual
comparisons seem to suggest that all went fine.  
 
Is there a way to get the attributes to be dumped in the order they are
declared in the schema?  it appears that they are sorted alphabetically.

so far xsd/cxx-tree seems to be a very useful package...

-Russ Johns


From boris at codesynthesis.com  Fri Jan  5 14:13:42 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:51 2009
Subject: [xsd-users] Attribute order on serialization.
In-Reply-To: <1168020848.10277.24.camel@gladiola.lanl.gov>
References: <1168020848.10277.24.camel@gladiola.lanl.gov>
Message-ID: <20070105191342.GD15118@karelia>

Hi Russell,

Russell C. Johns <johns@lanl.gov> writes:

> Is there a way to get the attributes to be dumped in the order they are
> declared in the schema?  it appears that they are sorted alphabetically.

No, I am afraid it is not possible. The C++/Tree runtime uses DOM to
serialize the in-memory representation to XML. DOM stores attributes
in a map with the attribute name as a key.

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/20070105/66a3404d/attachment.pgp
From beddoes at intient.com  Mon Jan  8 01:56:33 2007
From: beddoes at intient.com (Bradley Beddoes)
Date: Sun Oct 11 15:33:51 2009
Subject: [xsd-users] customising XSD to use ICU
Message-ID: <45A1EB21.3090307@intient.com>

Hi all,
At the moment I am attempting to customize XSD generated output to take 
advantage of the ICU library from (http://icu.sourceforge.net) to ensure 
we have true unicode support cross platform and aren't relying on the 
terrible wchar_t.

In particular at the moment I am redefining xsd:string to be represented 
by UnicodeString ( 
http://icu.sourceforge.net/apiref/icu4c/classUnicodeString.html ), I may 
look at UDate amongst others as well.

All has gone well so far until I got to enum and xsd:lang. Both of these 
seem to be causing me a fair deal of grief.

Firstly xml:lang as it seems simple enough, I can't seem to work out how 
to customize that type "--custom-type lang" does not seem to provide 
anything in my generated header at all, it seems to be generated as a 
struct internally to for example localizedURIType in the below schema. 
That in itself is not a problem but it generates constructors which take 
values of hard coded basic_string<char> instead of what I need which is 
xml_schema::string, any ideas how to fix this?

     <complexType name="localizedURIType">
         <simpleContent>
             <extension base="anyURI">
                 <attribute ref="xml:lang" use="required"/>
             </extension>
         </simpleContent>
     </complexType>

We regards to enums these appear to have the same constructor problem as 
noted about (use of basic_string<char>). Additionally I seem to be 
missing a non equivalence operator and I can't seem to figure out 
exactly what I need to implement (UnicodeString defines this method so 
its not that).

I have attached my generated header files

-- 
Bradley Beddoes
Lead Software Architect

Intient - "Open Source, Open Standards"


From beddoes at intient.com  Mon Jan  8 02:07:59 2007
From: beddoes at intient.com (Bradley Beddoes)
Date: Sun Oct 11 15:33:51 2009
Subject: [xsd-users] customising XSD to use ICU
In-Reply-To: <45A1EB21.3090307@intient.com>
References: <45A1EB21.3090307@intient.com>
Message-ID: <45A1EDCF.1030700@intient.com>

I have hit send on this a few minutes to early - damn short cut buttons 
and my big thumbs  ;) .

Attachments will be along in half an hour to and hour when I finish 
playing some more.


-- 
Bradley Beddoes
Lead Software Architect

Intient - "Open Source, Open Standards"


From boris at codesynthesis.com  Mon Jan  8 02:41:29 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:51 2009
Subject: [xsd-users] customising XSD to use ICU
In-Reply-To: <45A1EB21.3090307@intient.com>
References: <45A1EB21.3090307@intient.com>
Message-ID: <20070108074129.GA22889@karelia>

Hi Bradley,

Some quick notes before you send the code.

Bradley Beddoes <beddoes@intient.com> writes:

> At the moment I am attempting to customize XSD generated output to take
> advantage of the ICU library from (http://icu.sourceforge.net) to ensure
> we have true unicode support cross platform and aren't relying on the
> terrible wchar_t.

What is so terrible about wchar_t? It is true it can be 2 bytes long
(e.g., Windows) or 4 bytes (most UNIXes). XSD detects the size of
wchar_t and uses UTF-16 for 2-byte wchar_t and UTF-32/UCS-4 for
4-byte ones. If you don't search/test for characters outside the
Basic Plane (those that don't require 4-byte encoding in UTF-16)
then you should be fine. You can also write a small wrapper for
ICU if you do need to work with chars outside of the Basic Plane.

Another alternative would be to use char with UTF-8 encoding.


> In particular at the moment I am redefining xsd:string to be represented
> by UnicodeString (
> http://icu.sourceforge.net/apiref/icu4c/classUnicodeString.html ), I may
> look at UDate amongst others as well.

This is not going to be easy. The XSD runtime and generated code assume
an std::basic_string-based string and use string literals (e.g., "foo",
L"foo"). The best you could probably do is to customize all (or most)
of the user-visible API to use ICU UnicodeString but still use a char
(UTF-8) or wchar_t(UTF-16/32) -based encoding in the runtime, which may
not be too bad actually. You will probably need to derive from
UnicodeString and provide some constructors to allow implicit
construction from std::basic_string and string literals.

Another alternative would be to use std::basic_string with ICU Unicode
character type by using --char-type option (you will need to specialize
std::char_traits for this type). There could still be issues with
character literals though.


> Firstly xml:lang as it seems simple enough, I can't seem to work out how
> to customize that type "--custom-type lang" does not seem to provide
> anything in my generated header at all, it seems to be generated as a
> struct internally to for example localizedURIType in the below schema.

Are you using --morph-anonymous option? You will need to compile xml.xsd
with this option and --custom-type lang. The result will be a forward
declaration of struct lang; you will have to provide custom implementation.


> We regards to enums these appear to have the same constructor problem as
> noted about (use of basic_string<char>). Additionally I seem to be
> missing a non equivalence operator and I can't seem to figure out
> exactly what I need to implement (UnicodeString defines this method so
> its not that).

The problem with enums is that they use std::basic_string internally
as well as an array of string literals for enumerators. The only way
to overcome this (without using one of the strategies outlines above)
is to completely customize every string-based enum.

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/20070108/4f457fee/attachment.pgp
From beddoes at intient.com  Mon Jan  8 04:23:18 2007
From: beddoes at intient.com (Bradley Beddoes)
Date: Sun Oct 11 15:33:51 2009
Subject: [xsd-users] customising XSD to use ICU
In-Reply-To: <20070108074129.GA22889@karelia>
References: <45A1EB21.3090307@intient.com> <20070108074129.GA22889@karelia>
Message-ID: <45A20D86.1080603@intient.com>

Hi Boris,
Thanks for the information, I will have a bit more of a poke around and 
see what I can do before sending any code examples in, what you have 
said below about enums is the answer i was expecting I just wanted to 
check that out, I feel I should be able to make it work the way I need 
even with a little hand customization.

Some comments below:

Boris Kolpackov wrote:
> Hi Bradley,
> 
> Some quick notes before you send the code.
> 
> Bradley Beddoes <beddoes@intient.com> writes:
> 
>> At the moment I am attempting to customize XSD generated output to take
>> advantage of the ICU library from (http://icu.sourceforge.net) to ensure
>> we have true unicode support cross platform and aren't relying on the
>> terrible wchar_t.
> 
> What is so terrible about wchar_t? It is true it can be 2 bytes long
> (e.g., Windows) or 4 bytes (most UNIXes). XSD detects the size of
> wchar_t and uses UTF-16 for 2-byte wchar_t and UTF-32/UCS-4 for
> 4-byte ones. If you don't search/test for characters outside the
> Basic Plane (those that don't require 4-byte encoding in UTF-16)
> then you should be fine. You can also write a small wrapper for
> ICU if you do need to work with chars outside of the Basic Plane.

There is a possibility that in the future we'll need to look outside the 
  BMP its a minor one but there, more important is the fact that we need 
to use UTF-16 on every platform we are running on and be able to 
reliably perform a bunch of string manipulation and regex operations on 
those systems. ICU provides a very decent library for doing this along 
with some extensions which are present in boost.

There is a pretty good list of stuff I am looking to avoid here: 
http://icu.sourceforge.net/userguide/posix.html

> 
> Another alternative would be to use char with UTF-8 encoding.
> 
> 
>> In particular at the moment I am redefining xsd:string to be represented
>> by UnicodeString (
>> http://icu.sourceforge.net/apiref/icu4c/classUnicodeString.html ), I may
>> look at UDate amongst others as well.
> 
> This is not going to be easy. The XSD runtime and generated code assume
> an std::basic_string-based string and use string literals (e.g., "foo",
> L"foo"). The best you could probably do is to customize all (or most)
> of the user-visible API to use ICU UnicodeString but still use a char
> (UTF-8) or wchar_t(UTF-16/32) -based encoding in the runtime, which may
> not be too bad actually. You will probably need to derive from
> UnicodeString and provide some constructors to allow implicit
> construction from std::basic_string and string literals.

Yes this sounds about where I have gotten to right now with pretty much 
everything and it seems to be working ok thus far, though I am yet to 
perform extensive multilingual checks and this will probably take some time.

> 
> Another alternative would be to use std::basic_string with ICU Unicode
> character type by using --char-type option (you will need to specialize
> std::char_traits for this type). There could still be issues with
> character literals though.

Was looking to test this as well.

> 
> 
>> Firstly xml:lang as it seems simple enough, I can't seem to work out how
>> to customize that type "--custom-type lang" does not seem to provide
>> anything in my generated header at all, it seems to be generated as a
>> struct internally to for example localizedURIType in the below schema.
> 
> Are you using --morph-anonymous option? You will need to compile xml.xsd
> with this option and --custom-type lang. The result will be a forward
> declaration of struct lang; you will have to provide custom implementation.
> 

Excellent this is what I was after thanks.

> 
>> We regards to enums these appear to have the same constructor problem as
>> noted about (use of basic_string<char>). Additionally I seem to be
>> missing a non equivalence operator and I can't seem to figure out
>> exactly what I need to implement (UnicodeString defines this method so
>> its not that).
> 
> The problem with enums is that they use std::basic_string internally
> as well as an array of string literals for enumerators. The only way
> to overcome this (without using one of the strategies outlines above)
> is to completely customize every string-based enum.

I'll have a look into this in more depth, manually at first as I only 
have about 4 small enums at present but it may be worthwhile me 
investigating putting that support into the schema compilation process. 
Would you be interested in a patch?

regards,
Bradley

> 
> hth,
> -boris
> 


-- 
Bradley Beddoes
Lead Software Architect

Intient - "Open Source, Open Standards"


From johns at lanl.gov  Mon Jan  8 15:33:55 2007
From: johns at lanl.gov (Russ Johns)
Date: Sun Oct 11 15:33:51 2009
Subject: [xsd-users] issue creating document in memory 
Message-ID: <6.1.2.0.2.20070108125633.00ba85d0@beasley.lanl.gov>


Hi-

  I am trying to create a prototype app that creates an XML file from an in 
memory representation that is built up from scratch.
After getting a empty root element,  I get a access violation when I try to 
access the first sub element (minOccurs=maxOccurs=1)
The cxx-tree classes were created by xsd with the --generate-serialization 
and --generate-default-ctor options.

  the main routine  up to the point of error:

// SwordMemXml.cpp : Main function declaration, for test application that 
creates in memory representation .
//                   then serializes that to xml.

#include "SWORD-input.hpp"
#include <memory>
#include <iostream>
#include <fstream>
using std::cerr;
using std::endl;
using std::auto_ptr;

int main(int argc, char* argv[])
{
         try {
         // create SwordInput object
                 auto_ptr<SWORD::input::SwordInput> si (new 
SWORD::input::SwordInput());

                 // get element list
                 SWORD::input::ElementList el (si->elementlist());

  the code compiles,  appears to create a SwordInput object,  then gives a 
access violation in auto_ptr<>::get() apparently while trying to 
dereference the si variable to obtain the element list.

Is this how one would typically build up a representation?
I am using MS VS2005 and the latest stable xsd & xerces libs from the 
codesynthesis website.

I have done the same thing using the hello example problem,  but this 
problem seems to perform differently.

  the XML schema portions related to this are below.  I have also been able 
to round trip the XML file I am trying to create in a seperate executable. 
(XML->C++->XML)

Any suggestions as to how to fix the problem?

-Russ Johns

root element:
         <xs:element name="SWORD_input" type="SwordInput"/>
type is:
         <xs:complexType name="SwordInput">
                 <xs:sequence>
                         <xs:element name="elementlist" type="ElementList"/>
                         <xs:element name="materiallist" type="MaterialList"/>
                         <xs:element name="objectlist" type="ObjectList"/>
                         <xs:element name="rotationlist" type="RotationList"/>
                         <xs:element name="volumelist" type="VolumeList"/>
                         <xs:element name="world_positions" 
type="WorldPositions"/>
                         <xs:element name="energies" type="Energies"/>
                         <xs:element name="runinfo" type="RunInfo"/>
                 </xs:sequence>
         </xs:complexType>

where ElementList is defined as:
         <xs:complexType name="ElementList">
                 <xs:choice maxOccurs="unbounded">
                         <xs:element name="isotope" type="Isotope"/>
                         <xs:element name="element" type="Element"/>
                 </xs:choice>
         </xs:complexType>




From boris at codesynthesis.com  Mon Jan  8 15:31:41 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:51 2009
Subject: [xsd-users] customising XSD to use ICU
In-Reply-To: <45A20D86.1080603@intient.com>
References: <45A1EB21.3090307@intient.com> <20070108074129.GA22889@karelia>
	<45A20D86.1080603@intient.com>
Message-ID: <20070108203141.GC24581@karelia>

Hi Bradley,

Bradley Beddoes <beddoes@intient.com> writes:

> There is a pretty good list of stuff I am looking to avoid here:
> http://icu.sourceforge.net/userguide/posix.html

Thanks for pointing this to me, I will take a look.


> >The problem with enums is that they use std::basic_string internally
> >as well as an array of string literals for enumerators. The only way
> >to overcome this (without using one of the strategies outlines above)
> >is to completely customize every string-based enum.
>
> I'll have a look into this in more depth, manually at first as I only
> have about 4 small enums at present but it may be worthwhile me
> investigating putting that support into the schema compilation process.
> Would you be interested in a patch?

Sure, if you can come up with something clean. It won't be easy though.
The only way to provide string literals for non-char/wchar_t strings is
by manually creating an array of symbols, e.g.,

utf16_t hello[] = {'h', 'e', 'l', 'l', 'o', '\0'};

I think it will be much easier and cleaner to use say char/UTF-8 inside
the runtime for things like enum literals, element/attribute names, etc.
especially since they will hardly ever be outside ASCII.


BTW, when you manage to make everything work, perhaps you could create
a short Wiki write-up of the steps one needs to take to make the
generated code use ICU UnicodeString for xml_schema::string:

http://wiki.codesynthesis.com/

Or simply post the instructions to the mailing list and I will transfer
them to the Wiki. I would really appreciate it.


-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/20070108/52a482b8/attachment.pgp
From boris at codesynthesis.com  Mon Jan  8 15:51:55 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:51 2009
Subject: [xsd-users] issue creating document in memory
In-Reply-To: <6.1.2.0.2.20070108125633.00ba85d0@beasley.lanl.gov>
References: <6.1.2.0.2.20070108125633.00ba85d0@beasley.lanl.gov>
Message-ID: <20070108205155.GD24581@karelia>

Hi Russ,

Russ Johns <johns@lanl.gov> writes:

> After getting a empty root element,  I get a access violation when I try to
> access the first sub element (minOccurs=maxOccurs=1)
> The cxx-tree classes were created by xsd with the --generate-serialization
> and --generate-default-ctor options.

Here is a note from the XSD Command Line Interface Doc[1] for the
--generate-default-ctor option:

"Generate default constructors even for types that have required
 members. Required members of an instance constructed using such
 a constructor are not initialized and accessing them results in
 undefined behavior."

That's exactly what happens to you. The reason why we do not
generate default constructors by default (no pun intended) is
to force you to initialize the required members. If you choose
to use the default c-tor then you will need to initialize
required members before you can access them or serialize the
in-memory representation to XML. In your case you can do something
like this:

si->elementlist (SWORD::input::ElementList ()) // initialize element list

SWORD::input::ElementList& el (si->elementlist()); // get element list ref

Note also that I am using reference (ElementList&) instead of just
ElementList; this way you get a reference to the ElementList that
is inside si (so that you can populate it).

You can also use a more efficient way which avoids copying (not really
important in your case but can be for large sub-trees):

auto_ptr<SWORD::input::ElementList> el (
  new SWORD::input::ElementList (si.get ()));

// populate el here

si->elementlist (el); // transfer el to si




[1] http://www.codesynthesis.com/projects/xsd/documentation/xsd.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/20070108/f6b72ec1/attachment.pgp
From beddoes at intient.com  Mon Jan  8 23:54:46 2007
From: beddoes at intient.com (Bradley Beddoes)
Date: Sun Oct 11 15:33:51 2009
Subject: [xsd-users] customising XSD to use ICU
In-Reply-To: <20070108203141.GC24581@karelia>
References: <45A1EB21.3090307@intient.com> <20070108074129.GA22889@karelia>
	<45A20D86.1080603@intient.com> <20070108203141.GC24581@karelia>
Message-ID: <45A32016.50807@intient.com>

So I got a fair way with all of this, I had the UnicodeString integrated 
for most things but there were a number of problems:

- Firstly you need to write a lot of specific cases for your string 
class constructor, this is expected but be warned :).

- Comparison for things like enum seem to have const char* [*i] != *this 
generated so writing an overloaded != operator in my new string class 
was impossible (of course I did make this work by manually editing the 
positions, might be worth changing in the generation logic not sure).

- Exceptions. Most exception classes are hard wired to take 
basic_string<C>, in some cases multiple basic_strings, would be a lot of 
overhead to replace this and for some reasons I ran into problems when 
attempting to.

- Numero Uno problem... serialization, this I just cannot solve, I get 
so many errors when attempting to compile generated code with 
serialization enabled that I have little to no idea where to start, 
given timelines and the fact I need to have serialization work properly 
this seems a show stopper.

So I will revert back to using wchar_t my 2 days experiment didn't come 
to much fruition but thems the breaks, should anyone else ever pick this 
up in the future and are more successful then me drop me a note!.

I may look at some way of writing a thin wrapper or something for ICU if 
I have any outcomes in that dept I will report back.

cheers,
Bradley

-- 
Bradley Beddoes
Lead Software Architect

Intient - "Open Source, Open Standards"


From beddoes at intient.com  Tue Jan  9 04:30:31 2007
From: beddoes at intient.com (Bradley Beddoes)
Date: Sun Oct 11 15:33:51 2009
Subject: [xsd-users] serialization functions as members ?
Message-ID: <45A360B7.1010506@intient.com>

Hi,
Is there any way to have serialization functions generated as members of 
the actual class of your XSD type?.

For example:

<xsd:element name="Name" type="NameType"/>

This would currently generate the serialisation functions as standalone 
function calls for example like this:

void
Name (std::ostream&,
       const NameType&,
       const xml_schema::namespace_infomap&,
       const string& encoding = "UTF-8",
       xml_schema::flags = 0);

I am trying to write a generic marshaller library (integrated with 
xerces and xml security) and generating the serialization stuff this way 
make it impossible for me to do this. Instead is it possible to have for 
example:

class NameType
{
	public:
		void serialize (std::ostream&,
       const xml_schema::namespace_infomap&,
       const string& encoding = "UTF-8",
       xml_schema::flags = 0);

	....
}

??

This would allow me to define a generic function such as:

MyMarshaller::Marshall(T xmlObj)

Which would be able to serialize any object it was instantiated to serve 
at runtime which would really help enormously.

regards,
Bradley

-- 
Bradley Beddoes
Lead Software Architect

Intient - "Open Source, Open Standards"


From boris at codesynthesis.com  Tue Jan  9 07:15:57 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:51 2009
Subject: [xsd-users] serialization functions as members ?
In-Reply-To: <45A360B7.1010506@intient.com>
References: <45A360B7.1010506@intient.com>
Message-ID: <20070109121557.GA26825@karelia>

Hi Bradley,

Bradley Beddoes <beddoes@intient.com> writes:

> Is there any way to have serialization functions generated as members of
> the actual class of your XSD type?.
>
> For example:
>
> <xsd:element name="Name" type="NameType"/>
>
> This would currently generate the serialisation functions as standalone
> function calls for example like this:
>
> void
> Name (std::ostream&,
>       const NameType&,
>       const xml_schema::namespace_infomap&,
>       const string& encoding = "UTF-8",
>       xml_schema::flags = 0);
>
> I am trying to write a generic marshaller library (integrated with
> xerces and xml security) and generating the serialization stuff this way
> make it impossible for me to do this. Instead is it possible to have for
> example:
>
> class NameType
> {
> 	public:
> 		void serialize (std::ostream&,
>       const xml_schema::namespace_infomap&,
>       const string& encoding = "UTF-8",
>       xml_schema::flags = 0);
>
> 	....
> }
>
> ??
>
> This would allow me to define a generic function such as:
>
> MyMarshaller::Marshall(T xmlObj)
>
> Which would be able to serialize any object it was instantiated to serve
> at runtime which would really help enormously.

The reason why we generate serialization functions for global elements
instead of every type is because only such global elements are valid
document roots (as per XML Schema). Also generating a set of
serialization functions (about 10) for each type would result in quite
a lot of extra code that is not used.

The way to do what you want is to use serialization operators that
are generated for each type in the form:

void operator<< (DOMElement&, Type const&);

You can create a DOM document in your Marshall() function, serialize
 the instance to its root element, and then serialize DOM to XML.
You probably know how to do all this but, just in case, the following
FAQ section has some code:

http://wiki.codesynthesis.com/Tree/FAQ#Serialization


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/20070109/efeabab8/attachment.pgp
From boris at codesynthesis.com  Tue Jan  9 11:28:33 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:51 2009
Subject: [xsd-users] issue creating document in memory
In-Reply-To: <6.1.2.0.2.20070108154304.03926050@beasley.lanl.gov>
References: <6.1.2.0.2.20070108125633.00ba85d0@beasley.lanl.gov>
	<20070108205155.GD24581@karelia>
	<6.1.2.0.2.20070108154304.03926050@beasley.lanl.gov>
Message-ID: <20070109162833.GC26825@karelia>

Hi Russ,

Please keep xsd-users CC'ed to your future replies. This way others
who may have a similar problem will be able to find the answer in
the archives.

Russ Johns <johns@lanl.gov> writes:

>     It has been a while since I was a heavy c++ programmer (~1995).  From my
>    quick glance  at the default constructor:
>
>       SwordInput::
>        SwordInput ()
>        : ::xml_schema::type (),
>        _xsd_elementlist_ (::xml_schema::flags (), this),
>        _xsd_materiallist_ (::xml_schema::flags (), this),
>        _xsd_objectlist_ (::xml_schema::flags (), this),
>        _xsd_rotationlist_ (::xml_schema::flags (), this),
>        _xsd_volumelist_ (::xml_schema::flags (), this),
>        _xsd_world_positions_ (::xml_schema::flags (), this),
>        _xsd_energies_ (::xml_schema::flags (), this),
>        _xsd_runinfo_ (::xml_schema::flags (), this)
>        {
>        }
>
>    it looked like it was calling the default constructors on the nested
>    elements.

If you check the type of _xsd_elementlist_, you will see that is not
of type ElementList but rather of one<ElementList>, where 'one' is
a container, similar to auto_ptr.


>    The actual lists (e.g. SWORD::input::ElementList::element::container)
>    created by xsd-  are they STL vectors? with STL iterators?

They are not of std::vector though they use std::vector underneath.
The sequence container implements complete std::vector interface with
iterators conforming fully to the STL iterator interface (random access
in this case) so you can use sequence containers as if they were
std::vector's.

>    Understood-  the final app will have a number of routines to perform the
>    job of populating the tree,  so it would be a little difficult to grow the
>    tree completely from the bottom.

That's one of the reasons that persuaded us to add the
--generate-default-ctor option. But you must be careful since the
interface no longer enforces creation of fully-initialized tree nodes.


>      si->elementlist (SWORD::input::ElementList ()) // initialize element
>      list
>
>      SWORD::input::ElementList& el (si->elementlist()); // get element list
>      ref
>
>    This works well,  thanks-  I I just use the reference operator, (i.e. I
>    skip the initilizer) it makes it past the original error location but
>    fails the first time I try to add an element to the element list.

You *do* need to initialize the elementlist. The first line is not
optional.


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/20070109/4d29206b/attachment.pgp
From othman.fathy at gmail.com  Tue Jan  9 11:55:45 2007
From: othman.fathy at gmail.com (Othman Fathy)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] compliation error
Message-ID: <105ed6c40701090855v5b5d62cdj1605a3dc4968bffc@mail.gmail.com>

Hello,
  I have built the latest version of XSD using gcc 3.2 on windows using
Mingw shell, then I ran

 xsd.exe  cxx-tree smi_switch_confs.xsd

and it generated the c++ files correspond to this schema.
the problem when I compile this generated c++ files with gcc 3.3.1 I got
the  attached errors
Did anybody have this problem?

Thanks,
Othman

In file included from
l:/kry601/wg_server/miami/svd_xsd/exports.v3-2_0-0-1_engr-ixn/mgc_home/pkgs/xsd.ixn/libxsd/xsd/cxx/tree/exceptions.hxx:635,
                 from smi_switch_confs.hxx:49,
                 from
m:/oth_vista_v2_1_untested_nbld/s4c/perspecta_sc/perspecta_sc_sim/src/native/perspecta_kernel/smi_xml.cc:19:
l:/kry601/wg_server/miami/svd_modeltech/exports.v6-1_0-0-9_engr-ixn/mgc_home/pkgs/modeltech/gcc-
3.3.1-mingw32/include/c++/3.3.1/bits/basic_ios.h: In instantiation of
`std::basic_ios<wchar_t, std::char_traits<wchar_t> >':
l:/kry601/wg_server/miami/svd_xsd/exports.v3-2_0-0-1_engr-ixn/mgc_home/pkgs/xsd.ixn/libxsd/xsd/cxx/tree/exceptions.ixx:256:
instantiated from `std::basic_ostream<wchar_t, std::char_traits<wchar_t> >'
l:/kry601/wg_server/miami/svd_xsd/exports.v3-2_0-0-1_engr-ixn/mgc_home/pkgs/xsd.ixn/libxsd/xsd/cxx/tree/exceptions.ixx:256:
instantiated from here
l:/kry601/wg_server/miami/svd_modeltech/exports.v6-1_0-0-9_engr-ixn/mgc_home/pkgs/modeltech/gcc-
3.3.1-mingw32/include/c++/3.3.1/bits/basic_ios.h:67: error: no
   type named `pos_type' in `struct std::char_traits<wchar_t>'
l:/kry601/wg_server/miami/svd_modeltech/exports.v6-1_0-0-9_engr-ixn/mgc_home/pkgs/modeltech/gcc-
3.3.1-mingw32/include/c++/3.3.1/ostream: In instantiation of
`std::basic_ostream<wchar_t, std::char_traits<wchar_t> >':
l:/kry601/wg_server/miami/svd_xsd/exports.v3-2_0-0-1_engr-ixn/mgc_home/pkgs/xsd.ixn/libxsd/xsd/cxx/tree/exceptions.ixx:256:
instantiated from here
l:/kry601/wg_server/miami/svd_modeltech/exports.v6-1_0-0-9_engr-ixn/mgc_home/pkgs/modeltech/gcc-
3.3.1-mingw32/include/c++/3.3.1/ostream:64: error: no
   type named `pos_type' in `struct std::char_traits<wchar_t>'
l:/kry601/wg_server/miami/svd_modeltech/exports.v6-1_0-0-9_engr-ixn/mgc_home/pkgs/modeltech/gcc-
3.3.1-mingw32/include/c++/3.3.1/bits/ostream.tcc:422: error: no
   type named `pos_type' in `struct std::char_traits<wchar_t>'
l:/kry601/wg_server/miami/svd_modeltech/exports.v6-1_0-0-9_engr-ixn/mgc_home/pkgs/modeltech/gcc-
3.3.1-mingw32/include/c++/3.3.1/bits/ostream.tcc:433: error: no
   type named `pos_type' in `struct std::char_traits<wchar_t>'
l:/kry601/wg_server/miami/svd_modeltech/exports.v6-1_0-0-9_engr-ixn/mgc_home/pkgs/modeltech/gcc-
3.3.1-mingw32/include/c++/3.3.1/streambuf: In instantiation of
`std::basic_streambuf<wchar_t, std::char_traits<wchar_t> >':
l:/kry601/wg_server/miami/svd_modeltech/exports.v6-1_0-0-9_engr-ixn/mgc_home/pkgs/modeltech/gcc-
3.3.1-mingw32/include/c++/3.3.1/bits/ostream.tcc:413:   instantiated from
`std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT,
_Traits>::flush() [with _CharT = wchar_t, _Traits =
std::char_traits<wchar_t>]'
l:/kry601/wg_server/miami/svd_modeltech/exports.v6-1_0-0-9_engr-ixn/mgc_home/pkgs/modeltech/gcc-
3.3.1-mingw32/include/c++/3.3.1/bits/ostream.tcc:48:   instantiated from
`std::basic_ostream<_CharT,
_Traits>::sentry::sentry(std::basic_ostream<_CharT, _Traits>&) [with _CharT
= wchar_t, _Traits = std::char_traits<wchar_t>]'
l:/kry601/wg_server/miami/svd_modeltech/exports.v6-1_0-0-9_engr-ixn/mgc_home/pkgs/modeltech/gcc-
3.3.1-mingw32/include/c++/3.3.1/bits/ostream.tcc:672:   instantiated from
`std::basic_ostream<_CharT, _Traits>&
std::operator<<(std::basic_ostream<_CharT, _Traits>&, const
std::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = wchar_t, _Traits
= std::char_traits<wchar_t>, _Alloc = std::allocator<wchar_t>]'
l:/kry601/wg_server/miami/svd_xsd/exports.v3-2_0-0-1_engr-ixn/mgc_home/pkgs/xsd.ixn/libxsd/xsd/cxx/tree/exceptions.ixx:256:
instantiated from here
l:/kry601/wg_server/miami/svd_modeltech/exports.v6-1_0-0-9_engr-ixn/mgc_home/pkgs/modeltech/gcc-
3.3.1-mingw32/include/c++/3.3.1/streambuf:137: error: no
   type named `pos_type' in `struct std::char_traits<wchar_t>'
l:/kry601/wg_server/miami/svd_modeltech/exports.v6-1_0-0-9_engr-ixn/mgc_home/pkgs/modeltech/gcc-
3.3.1-mingw32/include/c++/3.3.1/streambuf:149: error: no
   type named `state_type' in `struct std::char_traits<wchar_t>'
l:/kry601/wg_server/miami/svd_modeltech/exports.v6-1_0-0-9_engr-ixn/mgc_home/pkgs/modeltech/gcc-
3.3.1-mingw32/include/c++/3.3.1/streambuf: In instantiation of
`std::basic_streambuf<wchar_t, std::char_traits<wchar_t> >':
l:/kry601/wg_server/miami/svd_modeltech/exports.v6-1_0-0-9_engr-ixn/mgc_home/pkgs/modeltech/gcc-
3.3.1-mingw32/include/c++/3.3.1/bits/ostream.tcc:413:   instantiated from
`std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT,
_Traits>::flush() [with _CharT = wchar_t, _Traits =
std::char_traits<wchar_t>]'
l:/kry601/wg_server/miami/svd_modeltech/exports.v6-1_0-0-9_engr-ixn/mgc_home/pkgs/modeltech/gcc-
3.3.1-mingw32/include/c++/3.3.1/bits/ostream.tcc:48:   instantiated from
`std::basic_ostream<_CharT,
_Traits>::sentry::sentry(std::basic_ostream<_CharT, _Traits>&) [with _CharT
= wchar_t, _Traits = std::char_traits<wchar_t>]'
l:/kry601/wg_server/miami/svd_modeltech/exports.v6-1_0-0-9_engr-ixn/mgc_home/pkgs/modeltech/gcc-
3.3.1-mingw32/include/c++/3.3.1/bits/ostream.tcc:672:   instantiated from
`std::basic_ostream<_CharT, _Traits>&
std::operator<<(std::basic_ostream<_CharT, _Traits>&, const
std::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = wchar_t, _Traits
= std::char_traits<wchar_t>, _Alloc = std::allocator<wchar_t>]'
l:/kry601/wg_server/miami/svd_xsd/exports.v3-2_0-0-1_engr-ixn/mgc_home/pkgs/xsd.ixn/libxsd/xsd/cxx/tree/exceptions.ixx:256:
instantiated from here
l:/kry601/wg_server/miami/svd_modeltech/exports.v6-1_0-0-9_engr-ixn/mgc_home/pkgs/modeltech/gcc-
3.3.1-mingw32/include/c++/3.3.1/streambuf:257: error: no
   type named `state_type' in `struct std::char_traits<wchar_t>'
l:/kry601/wg_server/miami/svd_modeltech/exports.v6-1_0-0-9_engr-ixn/mgc_home/pkgs/modeltech/gcc-
3.3.1-mingw32/include/c++/3.3.1/streambuf:413: error: no
   type named `pos_type' in `struct std::char_traits<wchar_t>'
l:/kry601/wg_server/miami/svd_modeltech/exports.v6-1_0-0-9_engr-ixn/mgc_home/pkgs/modeltech/gcc-
3.3.1-mingw32/include/c++/3.3.1/streambuf:418: error: no
   type named `pos_type' in `struct std::char_traits<wchar_t>'
l:/kry601/wg_server/miami/svd_modeltech/exports.v6-1_0-0-9_engr-ixn/mgc_home/pkgs/modeltech/gcc-
3.3.1-mingw32/include/c++/3.3.1/streambuf:726: error: no
   type named `pos_type' in `struct std::char_traits<wchar_t>'
l:/kry601/wg_server/miami/svd_modeltech/exports.v6-1_0-0-9_engr-ixn/mgc_home/pkgs/modeltech/gcc-
3.3.1-mingw32/include/c++/3.3.1/streambuf:738: error: no
   type named `pos_type' in `struct std::char_traits<wchar_t>'

From boris at codesynthesis.com  Tue Jan  9 12:05:35 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] compliation error
In-Reply-To: <105ed6c40701090855v5b5d62cdj1605a3dc4968bffc@mail.gmail.com>
References: <105ed6c40701090855v5b5d62cdj1605a3dc4968bffc@mail.gmail.com>
Message-ID: <20070109170535.GD26825@karelia>

Hi Othman,

Othman Fathy <othman.fathy@gmail.com> writes:

> the problem when I compile this generated c++ files with gcc 3.3.1 I got
> the  attached errors
> Did anybody have this problem?
>
> [...]
>
> 3.3.1-mingw32/include/c++/3.3.1/streambuf:738: error: no
>   type named `pos_type' in `struct std::char_traits<wchar_t>'

Implementation of the Standard C++ library that comes with g++
(libstdc++) does not support wchar_t on mingw (and cygwin), see
this page for more information:

http://www.mingw.org/MinGWiki/index.php/wide%20characters


There are a couple of ways in which you can address this:

1. Use char instead of wchar_t. You can still handling Unicode
   by using UTF-8 as an encoding.

2. Use a different Standard C++ library. STLPort is known to
   work. The build of XSD compiler itself uses this approach
   as described in the build instructions for Windows:

   http://www.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/20070109/8e028fcf/attachment.pgp
From boris at codesynthesis.com  Tue Jan  9 13:09:44 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] compliation error
In-Reply-To: <105ed6c40701091008q739be26bo85ee6abd0097111b@mail.gmail.com>
References: <105ed6c40701090855v5b5d62cdj1605a3dc4968bffc@mail.gmail.com>
	<20070109170535.GD26825@karelia>
	<105ed6c40701091008q739be26bo85ee6abd0097111b@mail.gmail.com>
Message-ID: <20070109180944.GE26825@karelia>

Hi Othman,

Please keep xsd-users CC'ed to your future replies. This way others
who may have a similar problem will be able to find the answer in
the archives.

Othman Fathy <othman.fathy@gmail.com> writes:

>  I like the first option, How can I use char insteady of wchar_t is there a
> switch or directive I have to use?

Hm, char is the default. You actually need to use "--char-type wchar_t"
to get wchar_t. Can you check that you are not passing this option when
compiling your schemas?

Another thing to check is that you do not include any headers from
the libxsd library before the generated headers.


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/20070109/389af06e/attachment.pgp
From othman.fathy at gmail.com  Tue Jan  9 14:25:23 2007
From: othman.fathy at gmail.com (Othman Fathy)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] compliation error
In-Reply-To: <20070109180944.GE26825@karelia>
References: <105ed6c40701090855v5b5d62cdj1605a3dc4968bffc@mail.gmail.com>
	<20070109170535.GD26825@karelia>
	<105ed6c40701091008q739be26bo85ee6abd0097111b@mail.gmail.com>
	<20070109180944.GE26825@karelia>
Message-ID: <105ed6c40701091125h56cc2facne365b0a248bb6c8f@mail.gmail.com>

Hi Boris,
  I am not passing any switches to the xsd when I compiled my schema, I
changed my compilation line to

xsd cxx-tree --char-type char smi_switch_confs.xsd

and I am still having the same errors, I am not including any headers from
the XSD tree except the generated headers.

Do you think that there is a problem on my XSD build that always generate
wchar_t types.

Thanks,
Othman


On 1/9/07, Boris Kolpackov <boris@codesynthesis.com> wrote:
>
> Hi Othman,
>
> Please keep xsd-users CC'ed to your future replies. This way others
> who may have a similar problem will be able to find the answer in
> the archives.
>
> Othman Fathy <othman.fathy@gmail.com> writes:
>
> >  I like the first option, How can I use char insteady of wchar_t is
> there a
> > switch or directive I have to use?
>
> Hm, char is the default. You actually need to use "--char-type wchar_t"
> to get wchar_t. Can you check that you are not passing this option when
> compiling your schemas?
>
> Another thing to check is that you do not include any headers from
> the libxsd library before the generated headers.
>
>
> hth,
> -boris
>
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.5 (GNU/Linux)
>
> iQGVAwUBRaPaaMiAKQuuCE8dAQIVsAwAxqI/MKCIZUabf0c7ivVgj0MovZ7gHFtt
> 04nBUM17x5EIuerLStjkD+DhNV6gILzR82CuIKZivyiocaUShcZIGIOqVG0ZgM3V
> Npdd8EYVP5C0IxluD9S+MSLt8zeQ9ymO9qImnQUU6kc/OwhH6BPwqlr7DSg513lb
> kpL6ycgcoFoLpGcinwH6q4cvaKtreR7DzQnkGeh9N2nQwwR/G3wgkZEmoiD9JmzU
> GqBnDnsRRvY6yqMxs2kkqqNuLwThXol1V2kaROlsVKs2FmwC6Q4HxN78BT8mAp30
> k8vXRlyXAYDn1O5HOb2+A9MhkEzgnRC0kuTSfQVdOI+dx7/VGReRhTi9SRUnlGAm
> vxfvbkGGg7jgFqxcNHj/+s/63JVITPunhNUDCBguabfCfH2ACSfEEFLvxFVyEdoI
> legUG2dUSToB/30reypdUsK7rVtfTldOh5WjKbd14uf+eESCqGmBXf84Y14/fwy8
> hteHijr5vg5oVvSkNoyWp/qXgadS8jDA
> =lFPf
> -----END PGP SIGNATURE-----
>
>
>

From boris at codesynthesis.com  Tue Jan  9 14:42:37 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] compliation error
In-Reply-To: <105ed6c40701091125h56cc2facne365b0a248bb6c8f@mail.gmail.com>
References: <105ed6c40701090855v5b5d62cdj1605a3dc4968bffc@mail.gmail.com>
	<20070109170535.GD26825@karelia>
	<105ed6c40701091008q739be26bo85ee6abd0097111b@mail.gmail.com>
	<20070109180944.GE26825@karelia>
	<105ed6c40701091125h56cc2facne365b0a248bb6c8f@mail.gmail.com>
Message-ID: <20070109194237.GF26825@karelia>

Hi Othman,

Othman Fathy <othman.fathy@gmail.com> writes:

> xsd cxx-tree --char-type char smi_switch_confs.xsd
>
> and I am still having the same errors, I am not including any headers from
> the XSD tree except the generated headers.
>
> Do you think that there is a problem on my XSD build that always generate
> wchar_t types.

No, I do not think so. If you look into libxsd/xsd/cxx/tree/exceptions.ixx
you will see that this file is split into two parts, one is for char, the
other one is for wchar_t. These parts are conditionally included or excluded
depending on the define in the generated code. You can check the generated
header files for XSD_CXX_TREE_USE_CHAR.

Which version of XSD are you using? Can you try to compile one of the
examples (e.g., hello in examples/cxx/tree) and let me know if you have
the same problem?

-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/20070109/8e46cb50/attachment.pgp
From jnw at xs4all.nl  Tue Jan  9 15:11:51 2007
From: jnw at xs4all.nl (Jeroen N. Witmond)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] anyAttribute without processContents: generated code
	fails to parse
Message-ID: <7819.194.109.230.85.1168373511.squirrel@webmail.xs4all.nl>

Greetings,

When in my schema I use <anyAttribute namespace="##other"/> without
processContents attribute, the code generated from it refuses to parse
the related xml file (error: Attribute
'{http://www.w3.org/XML/1998/namespace}base' is not declared for
element 'item'), while DOMPrint -n -s -f -v=always does not complain.
Adding processContents="lax" solves this problem.  I don't know where
the default for processContents is or should be defined, but I'm
intrigued by the difference in behavior between xsd's generated code
and (Xerces-C++ 2.6) DOMPrint.

Kind regards,

Jeroen.



From boris at codesynthesis.com  Tue Jan  9 15:03:27 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] anyAttribute without processContents: generated code
	fails to parse
In-Reply-To: <7819.194.109.230.85.1168373511.squirrel@webmail.xs4all.nl>
References: <7819.194.109.230.85.1168373511.squirrel@webmail.xs4all.nl>
Message-ID: <20070109200327.GA27817@karelia>

Hi Jeroen,

Jeroen N. Witmond <jnw@xs4all.nl> writes:

> When in my schema I use <anyAttribute namespace="##other"/> without
> processContents attribute, the code generated from it refuses to parse
> the related xml file (error: Attribute
> '{http://www.w3.org/XML/1998/namespace}base' is not declared for
> element 'item'), while DOMPrint -n -s -f -v=always does not complain.
> Adding processContents="lax" solves this problem.  I don't know where
> the default for processContents is or should be defined, but I'm
> intrigued by the difference in behavior between xsd's generated code
> and (Xerces-C++ 2.6) DOMPrint.

If you do not specify the processContents attribute, it defaults to
"strict" so the XSD is correct here. I am not sure why DOMPrint
behaves differently. Could be due to some differences in how parsing
is set up.


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/20070109/b18536f5/attachment.pgp
From jnw at xs4all.nl  Tue Jan  9 15:48:34 2007
From: jnw at xs4all.nl (Jeroen N. Witmond)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] Compile error on generated code with CXXFLAGS =
	-pedantic
Message-ID: <21425.194.109.230.85.1168375714.squirrel@webmail.xs4all.nl>

Greetings,

I like to compile all my c++ sources with g++ option -pedantic (together
with -W -Wall). When used on generated code, this results in "error: ISO
C++ does not support 'long long'" on these lines:
  typedef long long long_;
  typedef unsigned long long unsigned_long;
  typedef long long integer;
in namespace xml_schema.

I know I can hack around it by deleting these lines from the output of
`xsd cxx-tree --generate-xml-schema schema.xsd` and using that everywhere
else, but is there a better way to get around this?

Kind regards,

Jeroen.


From boris at codesynthesis.com  Tue Jan  9 15:57:28 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] Compile error on generated code with CXXFLAGS =
	-pedantic
In-Reply-To: <21425.194.109.230.85.1168375714.squirrel@webmail.xs4all.nl>
References: <21425.194.109.230.85.1168375714.squirrel@webmail.xs4all.nl>
Message-ID: <20070109205728.GB27817@karelia>

Hi Jeroen,

Jeroen N. Witmond <jnw@xs4all.nl> writes:

> I like to compile all my c++ sources with g++ option -pedantic (together
> with -W -Wall). When used on generated code, this results in "error: ISO
> C++ does not support 'long long'" on these lines:

They should have called this option -anal ;-) for pretty much every
C++ compiler supports long long.


> I know I can hack around it by deleting these lines from the output of
> `xsd cxx-tree --generate-xml-schema schema.xsd` and using that everywhere
> else, but is there a better way to get around this?

No need to hack those lines: you can always provide custom definitions
for the types you don't like as described in the C++/Tree Mapping
Customization Guide[1]:

xsd cxx-tree --generate-xml-schema --custom-type long=64bit_t schema.xsd

Where 64bit_t is a 64-bit signed integer type of your choice.


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/20070109/2dbd7824/attachment.pgp
From beddoes at intient.com  Thu Jan 11 06:13:02 2007
From: beddoes at intient.com (Bradley Beddoes)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] serializing ##other
Message-ID: <45A61BBE.1090400@intient.com>

Hi,

Boris firstly thanks for your suggestion re << operator for generic 
serialization this seems to be working a treat.

Secondly is there a search function for the mail list history? I 
couldn't seem to locate one and google wasn't much help.

Lastly its late here and I am about to call it a night but I thought 
before I went I might pose a quick question so that if you manage to 
have any ideas I can work with them tomorrow.

We have part of our schema defined as so:
<complexType final="#all" name="ExtensionsType">
         <sequence>
             <any namespace="##other" processContents="lax" 
maxOccurs="unbounded"/>
         </sequence>
     </complexType>

This ends up mapping to:
class ExtensionsType: public ::xml_schema::type

which is what you would expect and is accessible though:
public:
       struct Extensions
       {
         typedef ::saml2::metadata::ExtensionsType type;
         typedef ::xsd::cxx::tree::traits< type, wchar_t > traits;
         typedef ::xsd::cxx::tree::optional< type > container;
       };

For some reason when invoking the << operator the data that is in the 
source document is not being serialized. I have only spent about 30 
minutes on this thus far albiet somewhat distracted and will get into it 
in anger tomorrow. Any thoughts though on what may be causing that?

regards,
Bradley

-- 
Bradley Beddoes
Lead Software Architect

Intient - "Open Source, Open Standards"


From boris at codesynthesis.com  Thu Jan 11 16:06:01 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] serializing ##other
In-Reply-To: <45A61BBE.1090400@intient.com>
References: <45A61BBE.1090400@intient.com>
Message-ID: <20070111210601.GB1032@karelia>

Hi Bradley,

Bradley Beddoes <beddoes@intient.com> writes:

> Secondly is there a search function for the mail list history? I
> couldn't seem to locate one and google wasn't much help.

Not yet. But google should be good for that. Just add
site:codesynthesis.com to your search term (the added advantage
being that other resources such as docs, wiki, etc. are also
searched).


> We have part of our schema defined as so:
> <complexType final="#all" name="ExtensionsType">
>         <sequence>
>             <any namespace="##other" processContents="lax"
> maxOccurs="unbounded"/>
>         </sequence>
>     </complexType>
>
> For some reason when invoking the << operator the data that is in the
> source document is not being serialized.

Serialization does not yet support wildcards. In fact the data that
is associated with a wildcard is normally ignored and the only way
to get to it is to:

1. use DOM association (keep_dom flag) or

2. customize the type and extract the data in c-tor(DOMElement&).


The way to add support for wildcard serialization would be to
override the serialization operator and serialize the wildcard-
corresponding elements yourself. If you use DOM association then
you can just import the nodes from the associated DOM document
to the one into which you are serializing. If you use the custom
c-tor way then you will need to store the DOM sub-tree somehow
in the instance. One way to do this would be to create a mini
DOM document just for that instance and store the elements there
(as you probably know, in Xerces-C++ DOM an element always belongs
to some document).

This should all work nicely except that at the moment you cannot
override the generated serialization operator if you are also
generating the original mapping to inherit from (the operator<<
will be generated with the actual type name instead of the
(renamed) base type name). But I think in your case you can
implement ExtensionsType from scratch since there is nothing
there except the wildcard. I am also going to fix this bug
tomorrow so let me know if you need a binary with this fix.

I would also like to add better support for wildcards in the
generated code, including out of the box support for serialization.
The problem is it's non-trivial to get it right in general case
especially when there is no full validation in the generate code.
I think the first step would be to generate a set of accessors/
modifiers for each wildcard and store the raw DOM fragments that
correspond to them in the node.


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/20070111/289e0b5a/attachment.pgp
From romain.garrigues at c-s.cnes.fr  Fri Jan 12 11:44:18 2007
From: romain.garrigues at c-s.cnes.fr (Romain Garrigues)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] [Problem] Types not found.
Message-ID: <200701121643.l0CGhnL29504@cnes.fr>

Hello all,

I'm trying to use xsd executable to generate C++ from my XSD file.
My root xsd file includes 5 others xsd files.
I have some errors i can't resolve, all are of this type :

"error: Type not found in :outlineType"
"error: Type not found in :pointType"
...

But for example outlineType is defined in one of the 5 "secondary" files, but not where this error occurs.
I thought it was an include order problem, but it seems not to be (i have changed include order, and always the same errors)

I have tried to generate code with others XML data binding products (trial version, not interesting for me...), and there is no problem.

Maybe i have to change something in my xsd files, or options i have forgotten when using xsd.exe ...
Did somebody had the same problem while using C++ generation from xsd ?

Best regards.

Ps : Sorry for poor english.

----------------------------------------

Romain - Communication & Syst?mes

From boris at codesynthesis.com  Fri Jan 12 12:06:58 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] [Problem] Types not found.
In-Reply-To: <200701121643.l0CGhnL29504@cnes.fr>
References: <200701121643.l0CGhnL29504@cnes.fr>
Message-ID: <20070112170658.GA4438@karelia>

Hi Romain,

Romain Garrigues <romain.garrigues@c-s.cnes.fr> writes:

> I'm trying to use xsd executable to generate C++ from my XSD file.
> My root xsd file includes 5 others xsd files.
> I have some errors i can't resolve, all are of this type :
>
> "error: Type not found in :outlineType"
> "error: Type not found in :pointType"
> ...
>
> But for example outlineType is defined in one of the 5 "secondary" files,
> but not where this error occurs.

I think I know what's going on. You probably have one of the secondary
schemas that uses say outlineType which is defined in another secondary
schema, but that schema is not included directly but rather into the
"main" schema. While this is legal per XML Schema, XSD requires that
each included or imported schema file be self-sufficient since you will
need to compile each one of them. The way to fix your schemas would be
to include secondary schemas into each other where necessary.


> I have tried to generate code with others XML data binding
> products (trial version, not interesting for me...), and there is
> no problem.

Some data binding products employ the so called "One file per type"
generation schema which results in each type being generated into
a separate C++ file. XSD uses the so called "One file per schema"
approach where each XML Schema file results in one C++ file, with
the XML Schema include and import directives mapped to the C++
preprocessor #include directives. Since each schema file is compiled
separately, XSD requires that they be valid by themselves.


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/20070112/dc00d999/attachment.pgp
From jnw at xs4all.nl  Sat Jan 13 08:42:47 2007
From: jnw at xs4all.nl (Jeroen N. Witmond)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] Compile error on generated code with CXXFLAGS = 
	-pedantic
In-Reply-To: <20070109205728.GB27817@karelia>
References: <21425.194.109.230.85.1168375714.squirrel@webmail.xs4all.nl>
	<20070109205728.GB27817@karelia>
Message-ID: <7731.194.109.230.85.1168695767.squirrel@webmail.xs4all.nl>

Hi Boris,

Boris Kolpackov <boris@codesynthesis.com> writes:

> Jeroen N. Witmond <jnw@xs4all.nl> writes:
>
>> I like to compile all my c++ sources with g++ option -pedantic (together
>> with -W -Wall). When used on generated code, this results in "error: ISO
>> C++ does not support 'long long'" on these lines:
>
> They should have called this option -anal ;-) for pretty much every
> C++ compiler supports long long.
>
>
>> I know I can hack around it by deleting these lines from the output of
>> `xsd cxx-tree --generate-xml-schema schema.xsd` and using that
>> everywhere
>> else, but is there a better way to get around this?
>
> No need to hack those lines: you can always provide custom definitions
> for the types you don't like as described in the C++/Tree Mapping
> Customization Guide[1]:
>
> xsd cxx-tree --generate-xml-schema --custom-type long=64bit_t schema.xsd
>
> Where 64bit_t is a 64-bit signed integer type of your choice.

Just for the record and the mailing list archives: I find that I need
  --custom-type long=int64_t --custom-type unsignedLong=uint64_t
  --custom-type integer=int64_t
to get -pedantic to be quiet.  Types int64_t and uint64_t appear to be a
part of the C99 standard; at least on my Debian etch box, the code
generated with these options compiles automagically.

Jeroen.



From jnw at xs4all.nl  Sat Jan 13 11:24:53 2007
From: jnw at xs4all.nl (Jeroen N. Witmond)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] Attempting to access attribute xml:base.
In-Reply-To: <20061230175234.GB15258@karelia>
References: <8644.194.109.230.85.1166735973.squirrel@webmail.xs4all.nl>
	<20061222093548.GB20058@karelia>
	<19842.194.109.230.85.1167412462.squirrel@webmail.xs4all.nl>
	<20061230175234.GB15258@karelia>
Message-ID: <23487.194.109.230.85.1168705493.squirrel@webmail.xs4all.nl>

Hi Boris

"Boris Kolpackov" <boris@codesynthesis.com> writes:

> Jeroen N. Witmond <jnw@xs4all.nl> writes:
>
> > Thanks, I've got this to work in a test program, but I'm confused about
> > the code generated for xml.xsd. I used 'xsd cxx-tree --namespace-map
> > http://www.w3.org/XML/1998/namespace=XmlNamespace xml.xsd' and see that
> > the generated .cxx file does not contain any executable code, nor does
the
> > generated .hxx file declare anything in namespace XmlNamespace.  Instead
> > all code related to xml:base is in the files generated from my own .xsd
> > file.

For the source of this program, named 'explicit', see [3], on the left.

> xml.xsd defines four global attributes and an attribute group. Those are
> meant to be used via the ref="" attribute. As a result, there is nothing
> being generated for these constructs where they are defined (xml.xsd),
> only where they are used (your schema). XSD does not (yet) analyze the
> schema to detect such a (presumably rare) case where there is nothing
> useful being generated. So you still need to translate xml.xsd since
> there will be #include "xml.hxx" directives present in the code generated
> from your schema.

Just documenting the obvious: In this case, file xml.cxx can be
ignored, it does not need to be compiled, and file xml.o is not needed
by the linker.  One step beyond is not to use file xml.xsd at all, and
to create a dummy file xml.hxx.  This is demonstrated in file
Makefile.tricky for the program named 'explicit' mentioned above.

> > > If you want to allow say xml:base in all types in your schema then
> > > you may want to create a base type which includes only that attribute
> > > and then inherit all other types from it.
> >
> > Unfortunately, I need to be able to access xml:base in code generated
from
> > schemas I do not author, where the use of xml:base is covered by a
> > '<xs:anyAttribute namespace="##other"/>'.  So, instead of using a base
> > type in XML, I would need a base class in C++.  And unless I've missed
> > something, there is no way to tell xsd to generate its classes ': public
> > XmlNamespace' (for instance, where XmlNamespace is a class that
implements
> > access to xml:base.).
>
> There are a number of ways you can implement this (in the order of
> increasing sophistication):
>
>
> 1. Use DOM association. You can pass the xml_schema::flags::keep_dom flag
>    to one of the parsing functions which will result in the DOM nodes
>    corresponding to the tree nodes being accessible via the _node()
>    function. See Section 3.2, "Flags and Properties" of the C++/Tree
>    Mapping Manual[1] as well as 'mixed' example for more information.
>    Using the DOM API you can check for presence of the xml:base attribute.


I've got this to work.  See [3], the program named 'DOM_association' in
item 1 on the right.

Question: Shouldn't the Tree Mapping User Manual[4], in the paragraph
starting with "Keeping association with DOM nodes is useful for
dealing", explicitely mention that the use of the
xml_schema::flags::keep_dom flag requires the use of the flag
xml_schema::flags::dont_initialize as well?

Question: I thought I had to release whatever is returned from
DOMAttr::getValue(), but when I try this, it results in "*** glibc
detected *** double free or corruption (out): 0x080827f8 ***" at the
xercesc::XMLString::release().  Is the storage somehow released by
xml:transcode?

> 2. You can do pretty much what you've described above by customizing the
>    types that have <xs:anyAttribute namespace="##other"/> and check/extract
>    the xml:base attribute in the constructor. See the C++/Tree Mapping
>    Customization Guide[2] as well as the examples in the custom/ directory
>    for details.

Also gotten this to work.  See [3], the program named 'custom-types'
in item 2 on the right.

Unfortunately, but IMHO unavoidably, 'custom-types' still requires the
xml_schema::flags mentioned above.  Without them, the DOM is not
available during the execution of the bodies of the contructors of the
custom types.

> 3. This is a variation of (2), for cases where you have a lot of unrelated
>    types that all allow for <xs:anyAttribute namespace="##other"/>. In this
>    case you may want to customize the xml_schema::type class which
>    corresponds to XML Schema anyType and is a base for every generated
>    types. You can customize xml_schema::type by inheriting from the
>    original and checking for xml::base in the constructor. Again, see the
>    C++/Tree Mapping Customization Guide[2] and examples for details.
>
> [1]
http://www.codesynthesis.com/projects/xsd/documentation/cxx/tree/manual/#3.2
>
> [2] http://wiki.codesynthesis.com/Tree/Customization_guide

I'm not sure I understand what you are saying here, but it sounds like
making modifications to xsd's source.  As I'm not ready to do that
(yet, see below), I created a base class to handle the access to the
xml:base attribute instead (in files xml-base.*), and derived my
custom types from both the class generated by xsd and from this base
class.  See [3], the program named 'custom-xmlbase' in item 3 on the
right.

As expected, the driver logic in file custom-xmlbase.cpp is almost
identical to that in file explicit.cpp for program 'explicit'
mentioned at the top of this post.  The one notable difference is that
for simple types, but not for complex types, it is necessary to
qualify base() with xml_base:: (the name of my base class) to resolve
ambiguity.

Unfortunately, building this program fails with

g++ -g -Wall -W   xml-base.o custom-types.o driver.o test2.o  -lxerces-c
-o driver
xml-base.o: In function
`xsd::cxx::tree::traits<xsd::cxx::tree::uri<wchar_t,
xsd::cxx::tree::simple_type<xsd::cxx::tree::_type> >,
wchar_t>::create(xercesc_2_7::DOMAttr const&, xsd::cxx::tree::flags,
xsd::cxx::tree::_type*)':
/usr/include/xsd/cxx/tree/elements.hxx:735: undefined reference to
`xsd::cxx::tree::uri<wchar_t,
xsd::cxx::tree::simple_type<xsd::cxx::tree::_type>
>::uri(xercesc_2_7::DOMAttr const&, xsd::cxx::tree::flags,
xsd::cxx::tree::_type*)'
collect2: ld returned 1 exit status

File xml-base.cpp contains the following code fragment

        ::std::auto_ptr< base::type > r (
          base::traits::create (
            a.dom_attribute (),
            f | ::xml_schema::flags::not_root,
            &type));

which I presume is the cause of this problem.  As this code was copied
from code generated by xsd (from [3], on the left), and it seems that
the missing code is created in file driver.o in that case, but not
here, I'm a bit confused.

At the moment, the base class only implements the getters and the
setters for the xml:base attribute, and that only for chartype whar_t.
This is sufficient for my immediate needs, but I would like to see
options added to xsd to generate and use code for a full
implementation of the xml namespace, along the line you suggested, or
along the line I implemented it.  These options would be very similar
to the existing --generate-xml-schema and --extern-xml-schema
options. For instance '--generate-xml-namespace <schemafile>' would
generate the implementation, and '--with-xml-namespace <schemafile>
<type>' would instruct to use it for the type given.

I'm willing to try and implement this new feature in xsd.  Could you
point me to the source files where I would have to start this?

With kind regards,

Jeroen.

[3] http://www.xs4all.nl/~jnw/codesynthesis/xmlnamespace/index.html

[4] file:///usr/share/doc/xsd/cxx/tree/manual/index.xhtml#3.2 as
    installed by xsd_2.3.0-1_i386.deb.



From romain.garrigues at c-s.cnes.fr  Mon Jan 15 03:28:43 2007
From: romain.garrigues at c-s.cnes.fr (Romain Garrigues)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] [Problem] Types not found.
References: <200701121643.l0CGhnL29504@cnes.fr> <20070112170658.GA4438@karelia>
Message-ID: <200701150828.l0F8SEs15941@cnes.fr>

You were right.
If i add includes in secondary schemas, there is no more errors!
I will now try to use generated code.
Thanks for advice ! 

Best Regards.

----- Original Message ----- 
From: "Boris Kolpackov" <boris@codesynthesis.com>
To: "Romain Garrigues" <romain.garrigues@c-s.fr>
Cc: <xsd-users@codesynthesis.com>
Sent: Friday, January 12, 2007 6:06 PM
Subject: Re: [xsd-users] [Problem] Types not found.

Hi Romain,

Romain Garrigues <romain.garrigues@c-s.cnes.fr> writes:

> I'm trying to use xsd executable to generate C++ from my XSD file.
> My root xsd file includes 5 others xsd files.
> I have some errors i can't resolve, all are of this type :
>
> "error: Type not found in :outlineType"
> "error: Type not found in :pointType"
> ...
>
> But for example outlineType is defined in one of the 5 "secondary" files,
> but not where this error occurs.

I think I know what's going on. You probably have one of the secondary
schemas that uses say outlineType which is defined in another secondary
schema, but that schema is not included directly but rather into the
"main" schema. While this is legal per XML Schema, XSD requires that
each included or imported schema file be self-sufficient since you will
need to compile each one of them. The way to fix your schemas would be
to include secondary schemas into each other where necessary.


> I have tried to generate code with others XML data binding
> products (trial version, not interesting for me...), and there is
> no problem.

Some data binding products employ the so called "One file per type"
generation schema which results in each type being generated into
a separate C++ file. XSD uses the so called "One file per schema"
approach where each XML Schema file results in one C++ file, with
the XML Schema include and import directives mapped to the C++
preprocessor #include directives. Since each schema file is compiled
separately, XSD requires that they be valid by themselves.


hth,
-boris


From Gregorio.Arvilla at epvgroup.com  Mon Jan 15 18:20:33 2007
From: Gregorio.Arvilla at epvgroup.com (Gregorio Arvilla)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] Question about xsd
Message-ID: <H000006e0011e1b1.1168903233.mailx.epvgroup.com@MHS>

Hi There,
 
I downloaded xsd for HP-UX 11. I untar it but I'm getting the following
error
when trying to run it:
 
[/users/greg/xsd/xsd-2.3.0-hppa-hpux/bin]
[bilbo][greg] ./xsd
/usr/lib/dld.sl: Unresolved symbol: wctob (code)  from ./xsd
Abort(coredump)
 
 
I'm assuming that the executable in the bin directory is already
compiled
for the HP-UX platform. Is there something else that needs to
be done?
 
 
Any help you could provide would be greatly appreciated.
 
Thanks You


From beddoes at intient.com  Tue Jan 16 06:34:45 2007
From: beddoes at intient.com (Bradley Beddoes)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] possible break in exception hieracy?
Message-ID: <45ACB855.7030301@intient.com>

Hi Boris,
At the moment I am having some problems with my serialization  functions 
and couldn't seem to find what exception was being thrown.

After some careful tracing I tracked it to this in elements.txx:

if (p == 0)
           {
             if (e.isDefaultNamespace (xns.c_str ()))
             {
               return std::basic_string<C> ();
             }
             else
             {
               // 'xml' prefix requires special handling and Xerces folks
               // refuse to handle this in DOM so I have to do it myself.
               //
               if (ns == xml::bits::xml_namespace<C> ())
                 return xml::bits::xml_prefix<C> ();

               throw no_prefix ();
             }
           }

See how your throwing no_prefix() ? is that correct? The class no_prefix 
seems to be forward decl in elements.hxx but doesn't seem to be 
implemented from what I can see? It certainly doesn't appear to be part 
of the exceptions hierachy.

I cant quite understand why I am reaching this point to be honest, at 
the moment I am struggling with a serialization issue where if I feed 
the serializer an appropriate DOM element ( using overloaded << ) it 
will work the first time without problem, reseting all my pointers and 
so forth and running again results in this namespace conflict. It almost 
seems like I am not closing something properly, any ideas? I will stay 
on it with the debugger and let you know if I find the problem.

-- 
Bradley Beddoes
Lead Software Architect

Intient - "Open Source, Open Standards"


From raulh39 at tid.es  Tue Jan 16 06:50:49 2007
From: raulh39 at tid.es (Raul Huertas)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] Question about xsd
In-Reply-To: <H000006e0011e1b1.1168903233.mailx.epvgroup.com@MHS>
References: <H000006e0011e1b1.1168903233.mailx.epvgroup.com@MHS>
Message-ID: <45ACBC19.8040208@tid.es>

Gregorio Arvilla escribi?:
> Hi There,
>  
> I downloaded xsd for HP-UX 11. I untar it but I'm getting the following
> error
> when trying to run it:
>  
> [/users/greg/xsd/xsd-2.3.0-hppa-hpux/bin]
> [bilbo][greg] ./xsd
> /usr/lib/dld.sl: Unresolved symbol: wctob (code)  from ./xsd
> Abort(coredump)
>  
>   
Your system is unable to found a required shared library.

wctob is in /usr/lib/libc.2, so the problem is that your system it is 
unable to found it.

If you have ldd, try:

/usr/ccs/bin/ldd xsd

in my system it shows:
        /usr/lib/libc.2 =>      /usr/lib/libc.2
        /usr/lib/libdld.2 =>    /usr/lib/libdld.2
        /usr/lib/libc.2 =>      /usr/lib/libc.2
        /usr/lib/libm.2 =>      /usr/lib/libm.2


?Can you send us the output of the ldd program?



From beddoes at intient.com  Tue Jan 16 07:08:20 2007
From: beddoes at intient.com (Bradley Beddoes)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] possible break in exception hieracy?
In-Reply-To: <45ACB855.7030301@intient.com>
References: <45ACB855.7030301@intient.com>
Message-ID: <45ACC034.5030701@intient.com>

My problem below was and std::map of namespaces being truncated during 
copy from where it is defined for some reason which I yet to figure out 
and stumped by, the exception hierarchy question still stands.

Bradley Beddoes wrote:
> Hi Boris,
> At the moment I am having some problems with my serialization  functions 
> and couldn't seem to find what exception was being thrown.
> 
> After some careful tracing I tracked it to this in elements.txx:
> 
> if (p == 0)
>           {
>             if (e.isDefaultNamespace (xns.c_str ()))
>             {
>               return std::basic_string<C> ();
>             }
>             else
>             {
>               // 'xml' prefix requires special handling and Xerces folks
>               // refuse to handle this in DOM so I have to do it myself.
>               //
>               if (ns == xml::bits::xml_namespace<C> ())
>                 return xml::bits::xml_prefix<C> ();
> 
>               throw no_prefix ();
>             }
>           }
> 
> See how your throwing no_prefix() ? is that correct? The class no_prefix 
> seems to be forward decl in elements.hxx but doesn't seem to be 
> implemented from what I can see? It certainly doesn't appear to be part 
> of the exceptions hierachy.
> 
> I cant quite understand why I am reaching this point to be honest, at 
> the moment I am struggling with a serialization issue where if I feed 
> the serializer an appropriate DOM element ( using overloaded << ) it 
> will work the first time without problem, reseting all my pointers and 
> so forth and running again results in this namespace conflict. It almost 
> seems like I am not closing something properly, any ideas? I will stay 
> on it with the debugger and let you know if I find the problem.
> 


-- 
Bradley Beddoes
Lead Software Architect

Intient - "Open Source, Open Standards"


From boris at codesynthesis.com  Tue Jan 16 07:26:00 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] Question about xsd
In-Reply-To: <H000006e0011e1b1.1168903233.mailx.epvgroup.com@MHS>
References: <H000006e0011e1b1.1168903233.mailx.epvgroup.com@MHS>
Message-ID: <20070116122600.GA15228@karelia>

Hi Gregorio,

Gregorio Arvilla <Gregorio.Arvilla@epvgroup.com> writes:

> I downloaded xsd for HP-UX 11. I untar it but I'm getting the following
> error
> when trying to run it:
>
> [/users/greg/xsd/xsd-2.3.0-hppa-hpux/bin]
> [bilbo][greg] ./xsd
> /usr/lib/dld.sl: Unresolved symbol: wctob (code)  from ./xsd
>
>
> I'm assuming that the executable in the bin directory is already
> compiled for the HP-UX platform.

Yes, it is built for HP-UX and we test it on HP-UX 11.11 and 11.23
on PA-RISC as well as 11.23 on IA-64. Which version of HP-UX are
you using? You can find out by running 'uname -a'.

Also, I suggested by Raul, you may want to run ldd on the xsd binary.
For me on 11.11 it prints:

$ ldd ./xsd
         =>
        /usr/lib/libc.2 =>      /usr/lib/libc.2
        /usr/lib/libdld.2 =>    /usr/lib/libdld.2
        /usr/lib/libc.2 =>      /usr/lib/libc.2
        /usr/lib/libm.2 =>      /usr/lib/libm.2


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/20070116/9d2d2ffc/attachment.pgp
From boris at codesynthesis.com  Tue Jan 16 07:56:43 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] possible break in exception hieracy?
In-Reply-To: <45ACB855.7030301@intient.com>
References: <45ACB855.7030301@intient.com>
Message-ID: <20070116125643.GB15228@karelia>

Hi Bradley,

Bradley Beddoes <beddoes@intient.com> writes:

> See how your throwing no_prefix() ? is that correct? The class no_prefix
> seems to be forward decl in elements.hxx but doesn't seem to be
> implemented from what I can see? It certainly doesn't appear to be part
> of the exceptions hierachy.

Yes, you are right. I've added it to my TODO list for 2.4.0. Thanks for
reporting this!


-boris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 652 bytes
Desc: Digital signature
Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070116/22d14707/attachment.pgp
From boris at codesynthesis.com  Tue Jan 16 16:00:10 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] Question about xsd
In-Reply-To: <H000006e0011f1b5.1168969371.mailx.epvgroup.com@MHS>
References: <20070116122600.GA15228@karelia>
	<H000006e0011f1b5.1168969371.mailx.epvgroup.com@MHS>
Message-ID: <20070116210010.GA16367@karelia>

Hi Gregorio,

Please keep xsd-users CC'ed to your future replies. This way others
who may have a similar problem will be able to find the answer in
the archives.


Gregorio Arvilla <Gregorio.Arvilla@epvgroup.com> writes:

> HP-UX bilbo B.11.00 U 9000/785 2012868944 unlimited-user license
>
> ...
>
> I noticed that the version of HP-UX that I'm using is older than
> the one you are using. If this version is not supported, Is it
> possible to build xsd on this version? If so, how do I build it?

You can find the link to the build instructions for UNIX-like OSes
as well as XSD source code on this page:

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


An alternative approach would be to compile your schemas on another
box (e.g., GNU/Linux or Windows) and copy the generated code to the
HP-UX machine. This will work since the generated code is the
same for all platforms and the XSD runtime library is header-
only. This approach could be less time consuming if this version
of HP-UX is not your main development environment (i.e., you just
need to build your application for this platform among others).

Feel free to post to the mailing list if you run into any problems
or need assistance.


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/20070116/59688b1a/attachment.pgp
From boris at codesynthesis.com  Tue Jan 16 16:37:00 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] Attempting to access attribute xml:base.
In-Reply-To: <23487.194.109.230.85.1168705493.squirrel@webmail.xs4all.nl>
References: <8644.194.109.230.85.1166735973.squirrel@webmail.xs4all.nl>
	<20061222093548.GB20058@karelia>
	<19842.194.109.230.85.1167412462.squirrel@webmail.xs4all.nl>
	<20061230175234.GB15258@karelia>
	<23487.194.109.230.85.1168705493.squirrel@webmail.xs4all.nl>
Message-ID: <20070116213700.GB16367@karelia>

Hi Jeroen,

Sorry it took me so long to reply to your post.

Jeroen N. Witmond <jnw@xs4all.nl> writes:

> Just documenting the obvious: In this case, file xml.cxx can be
> ignored, it does not need to be compiled, and file xml.o is not needed
> by the linker.  One step beyond is not to use file xml.xsd at all, and
> to create a dummy file xml.hxx.

Thanks for mentioning this. I am sure someone will find this information
useful.


> Question: Shouldn't the Tree Mapping User Manual[4], in the paragraph
> starting with "Keeping association with DOM nodes is useful for
> dealing", explicitely mention that the use of the
> xml_schema::flags::keep_dom flag requires the use of the flag
> xml_schema::flags::dont_initialize as well?

XSD is being smart here: it check that you've passed keep_dom and
does not initialize the runtime. In other words keep_dom implies
dont_initialize.


> Question: I thought I had to release whatever is returned from
> DOMAttr::getValue(),

Pretty much everything returned by DOM API belongs to the DOM
document you are working with and is released when the document
is released. So you do not need to free the string returned from
DOMAttr::getValue(). See the Xerces-C++ Programming Guide for
more information:

http://xml.apache.org/xerces-c/program.html


> Unfortunately, but IMHO unavoidably, 'custom-types' still requires the
> xml_schema::flags mentioned above.  Without them, the DOM is not
> available during the execution of the bodies of the contructors of the
> custom types.

Not in all constructors, but in the one that has const DOMElement& as its
argument. The idea is to check for xml:base in that c-tor and store the
value in some data member.


> > 3. This is a variation of (2), for cases where you have a lot of unrelated
> >    types that all allow for <xs:anyAttribute namespace="##other"/>. In this
> >    case you may want to customize the xml_schema::type class which
> >    corresponds to XML Schema anyType and is a base for every generated
> >    types. You can customize xml_schema::type by inheriting from the
> >    original and checking for xml::base in the constructor. Again, see the
> >    C++/Tree Mapping Customization Guide[2] and examples for details.
> >
> > [1] http://www.codesynthesis.com/projects/xsd/documentation/cxx/tree/manual/#3.2
> >
> > [2] http://wiki.codesynthesis.com/Tree/Customization_guide
>
> I'm not sure I understand what you are saying here, but it sounds like
> making modifications to xsd's source.

No, you do not need to modify XSD source code, everything can be
accomplished by customization. There is an XML Schema anyType which
is mapped to xml_schema::type C++ class. This class is a root of the
hierarchy: every generated type inherits from this class (directly
or indirectly). One of its constructors is in the form:

type (const DOMElement& e, /*other stuff*/);

It is called every type an DOM element is parsed into a C++ class
(because every generated class always call its base c-tor) The idea
is to customize this type with the logic for handling of xml:base,
etc. Since this type is a base for all the generated types then
all generated types will automatically have this functionality.
Hope this makes sense.


> This is sufficient for my immediate needs, but I would like to see
> options added to xsd to generate and use code for a full
> implementation of the xml namespace, along the line you suggested, or
> along the line I implemented it.

I would much prefer to have this implemented using the customization
technique outlined above rather than adding options and code to XSD
to support this popular but still special case. If you could come up
with the customization of xml_schema::type that implements this then
we can definitely publish it in some form or another (e.g., in the
wiki).


> [3] http://www.xs4all.nl/~jnw/codesynthesis/xmlnamespace/index.html

That's an impressive document you have here. Are you going to keep
it permanently? If so then I would like to add a link to it from the
wiki. Also, the link in the caption of the page points to
codesynthesis.org, I think it should be codesynthesis.com.


thanks,
-boris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 652 bytes
Desc: Digital signature
Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070116/41f30e6d/attachment.pgp
From prokher at gmail.com  Wed Jan 17 07:10:20 2007
From: prokher at gmail.com (Alexander A. Prokhorov)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] How to create unassigned issue?
Message-ID: <200701171510.20355.prokher@gmail.com>

Hello.

I want to create unassigned issue, is it possible? Actually, I want do the 
following. I create issue and assign it only to developers group, not 
specific developer. Further one of developers in that group will take 
responsibility for that issue by himself. Is it possible? I see only one 
solution - create metauser "my_group" and assign assign issue to it. But this 
solution looks ugly.

Thank you for any ideas.


From boris at codesynthesis.com  Wed Jan 17 07:38:33 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] How to create unassigned issue?
In-Reply-To: <200701171510.20355.prokher@gmail.com>
References: <200701171510.20355.prokher@gmail.com>
Message-ID: <20070117123833.GB18829@karelia>

Hi Alexander,

Alexander A. Prokhorov <prokher@gmail.com> writes:

> I want to create unassigned issue, is it possible? Actually, I want do the
> following. I create issue and assign it only to developers group, not
> specific developer. Further one of developers in that group will take
> responsibility for that issue by himself. Is it possible? I see only one
> solution - create metauser "my_group" and assign assign issue to it. But
> this solution looks ugly.

I don't really understand your question in the context of XML Schema
to C++ data binding. Are you working on some specific schema that
describe concepts such as issue, developer, and group? This sounds
a lot like a bug/issue tracking application.


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/20070117/06be5d7b/attachment.pgp
From prokher at gmail.com  Wed Jan 17 08:44:10 2007
From: prokher at gmail.com (Alexander A. Prokhorov)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] How to create unassigned issue?
Message-ID: <200701171644.10614.prokher@gmail.com>

I am sorry, wrong list!
> Hello.
>
> I want to create unassigned issue, is it possible? Actually, I want do the
> following. I create issue and assign it only to developers group, not
> specific developer. Further one of developers in that group will take
> responsibility for that issue by himself. Is it possible? I see only one
> solution - create metauser "my_group" and assign assign issue to it. But
> this solution looks ugly.
>
> Thank you for any ideas.


From kjani at ThinkEngine.Net  Wed Jan 17 19:12:49 2007
From: kjani at ThinkEngine.Net (Jani, Kashyap)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] Compiling with Rogue wave
Message-ID: <DD3DB974C9894A4A81A1B8AAACF423F9020F76AA@thinkmailsrvr.bos.thinkengine.net>

Hello,

            I am trying to compile a c++ program which uses a file
generated by xsd version 2.3.0 and rogue wave 9. The compilation works
fine if I remove rogue wave include files from my make file, but as soon
as I add include files I get this error. 

 

/usr/include/xsd/cxx/tree/serialization.hxx: In function `void
xercesc_2_7::operator<<(xercesc_2_7::DOMElement&, bool)':

/usr/include/xsd/cxx/tree/serialization.hxx:236: error: `boolalpha' is
not a member of `std'

/usr/include/xsd/cxx/tree/serialization.hxx: In function `void
xercesc_2_7::operator<<(xercesc_2_7::DOMAttr&, bool)':

/usr/include/xsd/cxx/tree/serialization.hxx:244: error: `boolalpha' is
not a member of `std'

/usr/include/xsd/cxx/tree/serialization.hxx: In function `void
xercesc_2_7::operator<<(xercesc_2_7::DOMElement&, long double)':

/usr/include/xsd/cxx/tree/serialization.hxx:296: error: `fixed' is not a
member of `std'

/usr/include/xsd/cxx/tree/serialization.hxx: In function `void
xercesc_2_7::operator<<(xercesc_2_7::DOMAttr&, long double)':

/usr/include/xsd/cxx/tree/serialization.hxx:308: error: `fixed' is not a
member of `std'

 

 

I would really appreciate if any one have encountered the same problem
and can comment on this.

 

I am using gcc

 

Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-java-awt=gtk
--host=i386-redhat-linux

Thread model: posix

gcc version 3.4.5 20051201 (Red Hat 3.4.5-2)

 

 

Regards,

Kashyap Jani


From boris at codesynthesis.com  Thu Jan 18 10:49:39 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] Compiling with Rogue wave
In-Reply-To: <DD3DB974C9894A4A81A1B8AAACF423F9020F76AA@thinkmailsrvr.bos.thinkengine.net>
References: <DD3DB974C9894A4A81A1B8AAACF423F9020F76AA@thinkmailsrvr.bos.thinkengine.net>
Message-ID: <20070118154939.GA3104@karelia>

Hi Kashyap,

Jani, Kashyap <kjani@thinkengine.net> writes:


>             I am trying to compile a c++ program which uses a file
> generated by xsd version 2.3.0 and rogue wave 9.

Which product of Rogue Wave are you using?


> The compilation works fine if I remove rogue wave include files
> from my make file, but as soon as I add include files I get this
> error.

You mean you remove the Rogue Wave include path from the g++ command
line? If so then it seems like when you add those includes you are
switching to their standard C++ library.


> /usr/include/xsd/cxx/tree/serialization.hxx:236: error: `boolalpha' is
> not a member of `std'

boolalpha is a standard iostream manipulator that should be there.
Can you check if the Rogue Wave product you are using includes
the standard C++ library implementation.


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/20070118/5cf15b81/attachment.pgp
From rlischner at proteus-technologies.com  Thu Jan 18 16:45:29 2007
From: rlischner at proteus-technologies.com (Ray Lischner)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] Problem when serializing when schemaLocation has more
	than one namespace
Message-ID: <F1886AFB628EA94098943970F1563B89CAB082@LINUS.proteus-technologies.com>

I have a schema split across two files, each with its own namespace.
When I
serialize, I supply a namespace map with both namespaces. The resulting
schemaLocation attribute omits a space between them. The following patch
against 2.3.0 and 2.3.1.b2 fixes the problem:


--- libxsd/xsd/cxx/xml/dom/serialization.txx.orig	2007-01-18
15:57:24.000000000 -0500
+++ libxsd/xsd/cxx/xml/dom/serialization.txx	2007-01-18
15:58:05.000000000 -0500
@@ -172,6 +172,8 @@
               }
               else
               {
+                if (!schema_location.empty())
+                  schema_location += space;
                 schema_location += i->second.name + space +
i->second.schema;
               }
             }

--
Ray Lischner

-------------- next part --------------
A non-text attachment was scrubbed...
Name: schemaLocation.patch
Type: application/octet-stream
Size: 444 bytes
Desc: schemaLocation.patch
Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070118/c6564b81/schemaLocation.obj
From boris at codesynthesis.com  Fri Jan 19 01:13:22 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] Problem when serializing when schemaLocation has more
	than one namespace
In-Reply-To: <F1886AFB628EA94098943970F1563B89CAB082@LINUS.proteus-technologies.com>
References: <F1886AFB628EA94098943970F1563B89CAB082@LINUS.proteus-technologies.com>
Message-ID: <20070119061322.GA5222@karelia>

Hi Ray,

Ray Lischner <rlischner@proteus-technologies.com> writes:

> The resulting schemaLocation attribute omits a space between them.
> The following patch against 2.3.0 and 2.3.1.b2 fixes the problem:

Applied. The fix will appear in the upcoming 2.3.1. Thanks for the
bug report and the patch!

-boris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 652 bytes
Desc: Digital signature
Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070119/72babb52/attachment.pgp
From rlischner at proteus-technologies.com  Fri Jan 19 11:52:00 2007
From: rlischner at proteus-technologies.com (Ray Lischner)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] static_cast instead of reinterpret_cast in
	ace-cdr-stream-*.hxx
Message-ID: <F1886AFB628EA94098943970F1563B89CAB0AF@LINUS.proteus-technologies.com>

The ACE CDR stream insertion and extraction headers use
reinterpret_cast<> when they should use static_cast<>. A comment in the
code says that reinterpret_cast is necessary because the cast might
discard a sign. The comment is wrong. Section 5.2.10 of the standard
lists the conversions that reinterpret_cast<> can perform, and X to
unsigned X is not one of them. Section 5.2.9 lists the conversions that
static_cast<> can perform, and any allowed type conversion is permitted.
Section 4.7 tells us that X to unsigned X is a permissible type
conversion. I attached a patch against 2.3.1.b2. The patch also applies
to 2.3.0. (I used an attachment because my mailer wraps lines, and I
can't find a way to turn it off.)
--
Ray Lischner

-------------- next part --------------
A non-text attachment was scrubbed...
Name: reinterpret_cast.patch
Type: application/octet-stream
Size: 1845 bytes
Desc: reinterpret_cast.patch
Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070119/e1d7a448/reinterpret_cast.obj
From boris at codesynthesis.com  Fri Jan 19 12:43:23 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] static_cast instead of reinterpret_cast in
	ace-cdr-stream-*.hxx
In-Reply-To: <F1886AFB628EA94098943970F1563B89CAB0AF@LINUS.proteus-technologies.com>
References: <F1886AFB628EA94098943970F1563B89CAB0AF@LINUS.proteus-technologies.com>
Message-ID: <20070119174323.GB5222@karelia>

Hi Ray,

Ray Lischner <rlischner@proteus-technologies.com> writes:

> The ACE CDR stream insertion and extraction headers use
> reinterpret_cast<> when they should use static_cast<>.

True. I've made the change. Thanks for reporting this!

-boris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 652 bytes
Desc: Digital signature
Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070119/4bd3a51b/attachment.pgp
From kjani at ThinkEngine.Net  Fri Jan 19 12:57:17 2007
From: kjani at ThinkEngine.Net (Jani, Kashyap)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] Compiling with Rogue wave
Message-ID: <DD3DB974C9894A4A81A1B8AAACF423F9020F78E0@thinkmailsrvr.bos.thinkengine.net>

Hi Boris,
	I am using rogue wave source pro 9 and I was using Rogue wave's
standard C++ libraries instead of using native libraries on Red Hat ES
4. Once we compiled Rogue wave to use native C++ libraries it worked
fine. 

Regards and thanks,
Kashyap Jani

-----Original Message-----
From: Boris Kolpackov [mailto:boris@codesynthesis.com] 
Sent: Thursday, January 18, 2007 10:50 AM
To: Jani, Kashyap
Cc: xsd-users@codesynthesis.com
Subject: Re: [xsd-users] Compiling with Rogue wave

Hi Kashyap,

Jani, Kashyap <kjani@thinkengine.net> writes:


>             I am trying to compile a c++ program which uses a file
> generated by xsd version 2.3.0 and rogue wave 9.

Which product of Rogue Wave are you using?


> The compilation works fine if I remove rogue wave include files
> from my make file, but as soon as I add include files I get this
> error.

You mean you remove the Rogue Wave include path from the g++ command
line? If so then it seems like when you add those includes you are
switching to their standard C++ library.


> /usr/include/xsd/cxx/tree/serialization.hxx:236: error: `boolalpha' is
> not a member of `std'

boolalpha is a standard iostream manipulator that should be there.
Can you check if the Rogue Wave product you are using includes
the standard C++ library implementation.




hth,
-boris





From boris at codesynthesis.com  Fri Jan 19 12:58:32 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] Compiling with Rogue wave
In-Reply-To: <DD3DB974C9894A4A81A1B8AAACF423F9020F78E0@thinkmailsrvr.bos.thinkengine.net>
References: <DD3DB974C9894A4A81A1B8AAACF423F9020F78E0@thinkmailsrvr.bos.thinkengine.net>
Message-ID: <20070119175832.GC5222@karelia>

Hi Kashyap,

Jani, Kashyap <kjani@ThinkEngine.Net> writes:

> 	I am using rogue wave source pro 9 and I was using Rogue wave's
> standard C++ libraries instead of using native libraries on Red Hat ES
> 4. Once we compiled Rogue wave to use native C++ libraries it worked
> fine.

Great, thanks for letting us know. BTW, Rogue Wave has released their
standard C++ library implementation as an open source project on Apache:

http://incubator.apache.org/projects/stdcxx.html

I am sure the latest release has all the standard manipulators supported.


-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/20070119/4674298e/attachment.pgp
From kjani at ThinkEngine.Net  Fri Jan 19 13:10:20 2007
From: kjani at ThinkEngine.Net (Jani, Kashyap)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] Compiling with Rogue wave
Message-ID: <DD3DB974C9894A4A81A1B8AAACF423F9020F78E5@thinkmailsrvr.bos.thinkengine.net>

Yes,
	I think it does have that. But instead of spending time trying
to figure out why I was getting errors compiling both together using
their standard c++ implementation I thought it would be easier for now
to just compile rogue wave to use native c++. If I find any road blocks
down the road I will come back to this issue again...

Thanks for your prompt replies.

Regards,
Kashyap Jani


-----Original Message-----
From: Boris Kolpackov [mailto:boris@codesynthesis.com] 
Sent: Friday, January 19, 2007 12:59 PM
To: Jani, Kashyap
Cc: xsd-users@codesynthesis.com
Subject: Re: [xsd-users] Compiling with Rogue wave

Hi Kashyap,

Jani, Kashyap <kjani@ThinkEngine.Net> writes:

> 	I am using rogue wave source pro 9 and I was using Rogue wave's
> standard C++ libraries instead of using native libraries on Red Hat ES
> 4. Once we compiled Rogue wave to use native C++ libraries it worked
> fine.

Great, thanks for letting us know. BTW, Rogue Wave has released their
standard C++ library implementation as an open source project on Apache:

http://incubator.apache.org/projects/stdcxx.html

I am sure the latest release has all the standard manipulators
supported.


-boris


From jerome.dumesnil at gmail.com  Sun Jan 21 09:42:51 2007
From: jerome.dumesnil at gmail.com (=?ISO-8859-1?Q?J=E9r=F4me_Dumesnil?=)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] Issue with includes
Message-ID: <50f8db60701210642s5d00d4d0w15a4ba1edd0ad31e@mail.gmail.com>

Hi everybody,

Hi Patrick,
>
> Patrick Shinpaugh <pshinpaugh at vt.edu <http://codesynthesis.com/mailman/listinfo/xsd-users>> 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 tried to compil too, but I get some errors when compiling generated cpp
files with gcc 4.1.1 on linux x86.

As you said, I modified x3d-3.0.xsd to include
x3d-3.0-Web3dExtensionsPublic.xsd.
So I generate sources files with :

xsd cxx-tree --morph-anonymous --root-element X3D --hxx-suffix .h
--cxx-suffix .cpp --output-dir src/ x3d-3.0.xsd
xsd cxx-tree --morph-anonymous --root-element X3D --hxx-suffix .h
--cxx-suffix .cpp --output-dir src/ x3d-3.0-Web3dExtensionsPublic.xsd
xsd cxx-tree --morph-anonymous --root-element X3D --hxx-suffix .h
--cxx-suffix .cpp --output-dir src/ x3d-3.0-Web3dExtensionsPublic.xsd

And after, I moved to src directory and I compiled them with :
gcc -c x3d-3.0.cpp

and I get this erros about "IS" :

x3d-3.0-Web3dExtensionsPublic.h:277: erreur: 'IS' in namespace '::' does not
name a type
x3d-3.0-Web3dExtensionsPublic.h:278: erreur: 'type' was not declared in this
scope
x3d-3.0-Web3dExtensionsPublic.h:278: erreur: patron de l'argument 1 est
invalide
x3d-3.0-Web3dExtensionsPublic.h:279: erreur: 'type' was not declared in this
scope
x3d-3.0-Web3dExtensionsPublic.h:279: erreur: patron de l'argument 1 est
invalide
x3d-3.0-Web3dExtensionsPublic.h:279: erreur: patron de l'argument 2 est
invalide
x3d-3.0-Web3dExtensionsPublic.h:289: erreur: expected unqualified-id before
'&' token
x3d-3.0-Web3dExtensionsPublic.h:289: erreur: expected ',' or '...' before
'&' token
x3d-3.0-Web3dExtensionsPublic.h:289: erreur: ISO C++ forbids declaration of
'parameter' with no type
x3d-3.0-Web3dExtensionsPublic.h:295: erreur: 'type' is not a member of
'XvlShell::IS'
x3d-3.0-Web3dExtensionsPublic.h:295: erreur: 'type' is not a member of
'XvlShell::IS'
x3d-3.0-Web3dExtensionsPublic.h:295: erreur: patron de l'argument 1 est
invalide
x3d-3.0-Web3dExtensionsPublic.h:295: erreur: 'void XvlShell::IS(int)' cannot
be overloaded
x3d-3.0-Web3dExtensionsPublic.h:289: erreur: with 'void XvlShell::IS(int)'
x3d-3.0-Web3dExtensionsPublic.h:302: erreur: 'MetadataDouble' in namespace
'::' does not name a type
x3d-3.0-Web3dExtensionsPublic.h:303: erreur: 'type' was not declared in this
scope
x3d-3.0-Web3dExtensionsPublic.h:303: erreur: patron de l'argument 1 est
invalide
x3d-3.0-Web3dExtensionsPublic.h:304: erreur: 'type' was not declared in this
scope
x3d-3.0-Web3dExtensionsPublic.h:304: erreur: patron de l'argument 1 est
invalide
x3d-3.0-Web3dExtensionsPublic.h:304: erreur: patron de l'argument 2 est
invalide
x3d-3.0-Web3dExtensionsPublic.h:314: erreur: expected unqualified-id before
'&' token
x3d-3.0-Web3dExtensionsPublic.h:314: erreur: expected ',' or '...' before
'&' token
x3d-3.0-Web3dExtensionsPublic.h:314: erreur: ISO C++ forbids declaration of
'parameter' with no type
x3d-3.0-Web3dExtensionsPublic.h:320: erreur: 'type' is not a member of
'XvlShell::MetadataDouble'
x3d-3.0-Web3dExtensionsPublic.h:320: erreur: 'type' is not a member of
'XvlShell::MetadataDouble'
x3d-3.0-Web3dExtensionsPublic.h:320: erreur: patron de l'argument 1 est
invalide
x3d-3.0-Web3dExtensionsPublic.h:320: erreur: 'void
XvlShell::MetadataDouble(int)' cannot be overloaded
x3d-3.0-Web3dExtensionsPublic.h:314: erreur: with 'void
XvlShell::MetadataDouble(int)'
x3d-3.0-Web3dExtensionsPublic.h:327: erreur: 'MetadataFloat' in namespace
'::' does not name a type
x3d-3.0-Web3dExtensionsPublic.h:328: erreur: 'type' was not declared in this
scope
x3d-3.0-Web3dExtensionsPublic.h:328: erreur: patron de l'argument 1 est
invalide
x3d-3.0-Web3dExtensionsPublic.h:329: erreur: 'type' was not declared in this
scope
x3d-3.0-Web3dExtensionsPublic.h:329: erreur: patron de l'argument 1 est
invalide
x3d-3.0-Web3dExtensionsPublic.h:329: erreur: patron de l'argument 2 est
invalide
x3d-3.0-Web3dExtensionsPublic.h:339: erreur: expected unqualified-id before
'&' token
x3d-3.0-Web3dExtensionsPublic.h:339: erreur: expected ',' or '...' before
'&' token
x3d-3.0-Web3dExtensionsPublic.h:339: erreur: ISO C++ forbids declaration of
'parameter' with no type
x3d-3.0-Web3dExtensionsPublic.h:345: erreur: 'type' is not a member of
'XvlShell::MetadataFloat'
x3d-3.0-Web3dExtensionsPublic.h:345: erreur: 'type' is not a member of
'XvlShell::MetadataFloat'
x3d-3.0-Web3dExtensionsPublic.h:345: erreur: patron de l'argument 1 est
invalide
x3d-3.0-Web3dExtensionsPublic.h:345: erreur: 'void
XvlShell::MetadataFloat(int)' cannot be overloaded
x3d-3.0-Web3dExtensionsPublic.h:339: erreur: with 'void
XvlShell::MetadataFloat(int)'
x3d-3.0-Web3dExtensionsPublic.h:352: erreur: 'MetadataInteger' in namespace
'::' does not name a type
x3d-3.0-Web3dExtensionsPublic.h:353: erreur: 'type' was not declared in this
scope
x3d-3.0-Web3dExtensionsPublic.h:353: erreur: patron de l'argument 1 est
invalide
x3d-3.0-Web3dExtensionsPublic.h:354: erreur: 'type' was not declared in this
scope
x3d-3.0-Web3dExtensionsPublic.h:354: erreur: patron de l'argument 1 est
invalide
x3d-3.0-Web3dExtensionsPublic.h:354: erreur: patron de l'argument 2 est
invalide
x3d-3.0-Web3dExtensionsPublic.h:364: erreur: expected unqualified-id before
'&' token
x3d-3.0-Web3dExtensionsPublic.h:364: erreur: expected ',' or '...' before
'&' token
x3d-3.0-Web3dExtensionsPublic.h:364: erreur: ISO C++ forbids declaration of
'parameter' with no type
x3d-3.0-Web3dExtensionsPublic.h:370: erreur: 'type' is not a member of
'XvlShell::MetadataInteger'
x3d-3.0-Web3dExtensionsPublic.h:370: erreur: 'type' is not a member of
'XvlShell::MetadataInteger'
x3d-3.0-Web3dExtensionsPublic.h:370: erreur: patron de l'argument 1 est
invalide
x3d-3.0-Web3dExtensionsPublic.h:370: erreur: 'void
XvlShell::MetadataInteger(int)' cannot be overloaded
x3d-3.0-Web3dExtensionsPublic.h:364: erreur: with 'void
XvlShell::MetadataInteger(int)'
x3d-3.0-Web3dExtensionsPublic.h:377: erreur: 'MetadataSet' in namespace '::'
does not name a type
x3d-3.0-Web3dExtensionsPublic.h:378: erreur: 'type' was not declared in this
scope
x3d-3.0-Web3dExtensionsPublic.h:378: erreur: patron de l'argument 1 est
invalide
x3d-3.0-Web3dExtensionsPublic.h:379: erreur: 'type' was not declared in this
scope
x3d-3.0-Web3dExtensionsPublic.h:379: erreur: patron de l'argument 1 est
invalide
x3d-3.0-Web3dExtensionsPublic.h:379: erreur: patron de l'argument 2 est
invalide
x3d-3.0-Web3dExtensionsPublic.h:389: erreur: expected unqualified-id before
'&' token
x3d-3.0-Web3dExtensionsPublic.h:389: erreur: expected ',' or '...' before
'&' token
...

So, can you tell me what's wrong with "IS" ??
Thank you

JayDee

From boris at codesynthesis.com  Sun Jan 21 12:04:06 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] Issue with includes
In-Reply-To: <50f8db60701210642s5d00d4d0w15a4ba1edd0ad31e@mail.gmail.com>
References: <50f8db60701210642s5d00d4d0w15a4ba1edd0ad31e@mail.gmail.com>
Message-ID: <20070121170406.GA20900@karelia>

Hi J?r?me,

J?r?me Dumesnil <jerome.dumesnil@gmail.com> writes:


> As you said, I modified x3d-3.0.xsd to include
> x3d-3.0-Web3dExtensionsPublic.xsd.

It is the other way around: modify x3d-3.0-Web3dExtensionsPublic.xsd to
include x3d-3.0.xsd.

> So I generate sources files with :
>
> xsd cxx-tree --morph-anonymous --root-element X3D --hxx-suffix .h
> --cxx-suffix .cpp --output-dir src/ x3d-3.0.xsd
> xsd cxx-tree --morph-anonymous --root-element X3D --hxx-suffix .h
> --cxx-suffix .cpp --output-dir src/ x3d-3.0-Web3dExtensionsPublic.xsd
> xsd cxx-tree --morph-anonymous --root-element X3D --hxx-suffix .h
> --cxx-suffix .cpp --output-dir src/ x3d-3.0-Web3dExtensionsPublic.xsd
>
> And after, I moved to src directory and I compiled them with :
> gcc -c x3d-3.0.cpp

I just tried these exact options and it works fine for me with both
gcc 3.3.6 and 4.1.2. I assume you are using a recent version of
XSD (e.g., 3.2.0 or 3.2.1.b2).


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/20070121/607b7c5a/attachment.pgp
From boris at codesynthesis.com  Tue Jan 23 07:28:31 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] XSD 2.3.1 released
Message-ID: <20070123122831.GC15813@karelia>


Hi,

We have released XSD 2.3.1. This is a maintenance release containing
bug fixes, non-invasive new features, as well as ports to new platforms
and compilers. The NEWS file entries for this version are as follows:

  * The compiler is now capable of translating multiple schemas with
    one invocation.

  * New option, --sloc-limit, allows one to limit the amount of the
    generated code.

  * New option, --proprietary-license, instructs the compiler not to
    include the GPL banner in each generated file. Instead a short
    notice about a required proprietary license is generated. You
    should not use this option unless you have obtained a proprietary
    license from Code Synthesis Tools CC.

  * The default encoding for the 'char' character type is now UTF-8.
    To get the previous behavior (local code page via the Xerces-C++
    transcode functions) define the XSD_USE_LCP preprocessor macro
    when compiling your source code.

  C++/Tree

    * The --parts option has been improved to split generated code more
      evenly by analyzing the complexity of the generated schema constructs.

    * Ability to customize serialization, std::ostream, and binary
      insertion/extraction operators. See examples/cxx/tree/custom/wildcard
      for an example on how to handle XML Schema wildcards (xsd:any and
      xsd:anyAttribute) by customizing the parsing constructor and
      serialization operators.

    * Optimizations for the run-time memory consumption.

    * Optimizations for space in the generated code.

    * Number of bug fixes.

  C++/Parser

    * Proper handling of an xsd:any nested content. Nested elements,
      attributes, and text are reported via _any_* hooks of the current
      parser.

    * Number of bug fixes, mostly in the generated validation code.


This release adds support for Intel C++ 9.1 and IBM XL C++ 7.0 and
8.0 as well as for AIX on POWER/PowerPC and GNU/Linux on IA-64.

In addition, starting with this release, we provides a Windows
Installer (.msi) package for XSD which also includes precompiled
Xerces-C++ libraries for Visual Studio .NET 2003 (VC++ 7.1) and
Visual Studio 2005 (VC++ 8.0).

Thanks to the following individuals for reporting bugs as well as
suggesting fixes and improvements:


Deane Yang         <deane at kalotay.com>
Raul Huertas       <raulh39 at tid.es>
Patrick Shinpaugh  <shpatric at vt.edu>
Jason Wang         <jwang at saic-asd.com>
Martin Nickolas    <marty at tibra.com.au>
Greg Carter        <greg at permedia.ca>
Lixuesong          <givemenews at tom.com>
Harish Prasad      <harish_tak at yahoo.com>
Eric Hasan         <shasan at mitre.org>
David J Stockdill  <dstockdi at csc.com>
David R Moss       <david.r.moss at selex-comm.com>
Bradley Beddoes    <beddoes at intient.com>
Jeroen N. Witmond  <jnw at xs4all.nl>
Ray Lischner       <rlischner at proteus-technologies.com>


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

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


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

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


SHA1 checksums for the files:


022b7caba36f4d8403bd3762f83f89ea4df860a6  xsd-2.3.1.tar.bz2
98668ea4be0219e216daa096ea48a35ef104ce81  xsd-2.3.1-powerpc-aix.tar.gz
c6d012c9a0fbb6aa479b4960852e8c80ebe0bb1f  xsd_2.3.1-1_i386.deb
6430dfc54dc5a69dbc7c193f06ff6dd4916b2e0a  xsd-2.3.1-1.i686.rpm
1b810f282b5208b0b8c960ef433e8d82645bda21  xsd-2.3.1-i686-linux-gnu.tar.bz2
ef1ce83500250234260eb0be4d5c45bfb34e0d95  xsd_2.3.1-1_amd64.deb
4249c4a2fccbc9ed60d79c89381574d649976f47  xsd-2.3.1-1.x86_64.rpm
30804241d449319ae64a0909070c8494f3c4ecb6  xsd-2.3.1-x86_64-linux-gnu.tar.bz2
108dda39e4e95fdd683be068968bd406311cec41  xsd-2.3.1-powerpc-linux-gnu.tar.bz2
39ab7b4f7c0d91b5dbf3c04b824e9409fa0de932  xsd-2.3.1-ia64-linux-gnu.tar.bz2
f202dea6dc0c7a209422ad5c9b4461edf19459da  xsd-2.3.1-hppa-hpux.tar.gz
f98c5655779f156fdd31e428de6863d83bfbc599  xsd-2.3.1-hppa-hpux.tar.bz2
40bb5a346411f81354ae260d485e1c6fe274e3fe  xsd-2.3.1-powerpc-macosx.tar.bz2
0e4052c53daedbaa495c04b427217374c38eb0ab  xsd-2.3.1-sparc-solaris.tar.gz
239bde0d5d23153fa1127b0e7ca55f30a5c11bbc  xsd-2.3.1-sparc-solaris.tar.bz2
8909d13bcfef39eb22be951a421cc22553b6959d  xsd-2.3.1-i686-solaris.tar.gz
7bc1a2a028ad4a7e2c84bced1385ab3ffb984c84  xsd-2.3.1-i686-solaris.tar.bz2
ac6db520f6c63532630816ea314d32c7a2ec9cd0  xsd-2.3.msi
02f6e90edccc0d0f14a96ed059f09f1b4212e4df  xsd-2.3.1-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/20070123/1de09462/attachment.pgp
From Gregorio.Arvilla at epvgroup.com  Tue Jan 23 14:08:35 2007
From: Gregorio.Arvilla at epvgroup.com (Gregorio Arvilla)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] Question about xsd
In-Reply-To: <20070123164620.GH15813@karelia>
Message-ID: <H000006e00128384.1169579314.mailx.epvgroup.com@MHS>

Hello Boris,

Thank you for your interest.

I regret to say that I have not been able to compile xsd on
a HP-UX 11.00 machine. I don't have a lot of experince on 
UNIX environments and I'm learning everything I can about them. 
The project requires that I use the aCC compiler and the 
Korn shell. I followed the build instructions from 
http://www.codesynthesis.com/projects/xsd/extras/build-unix.xhtml.
I have not even been able to compile the first package, build-0.2.2.tar.bz2,
this is what I get:

# make install install_prefix=/users/greg/xsd_codeSynthesis/build-0.2.2
Make: Cannot read or get .  Stop.
#

I guess there is something wrong with the makefiles so the next thing I
will do is try to somehow debug them.

Thank You

Gregorio


-----Original Message-----
From: Boris Kolpackov [mailto:boris@codesynthesis.com]
Sent: Tuesday, January 23, 2007 9:46 AM
To: Gregorio Arvilla
Cc: boris@codesynthesis.com
Subject: Re: [xsd-users] Question about xsd


Hi Gregorio,

Did you manage to compile XSD on your HP-UX 11 box?

-boris



Gregorio Arvilla <Gregorio.Arvilla@epvgroup.com> writes:

> I noticed that the version of HP-UX that I'm using is older than
> the one you are using. If this version is not supported, Is it
> possible to build xsd on this version? If so, how do I build it?


From boris at codesynthesis.com  Tue Jan 23 15:04:23 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] Question about xsd
In-Reply-To: <H000006e00128384.1169579314.mailx.epvgroup.com@MHS>
References: <20070123164620.GH15813@karelia>
	<H000006e00128384.1169579314.mailx.epvgroup.com@MHS>
Message-ID: <20070123200423.GA3095@karelia>

Hi Gregorio,

Gregorio Arvilla <Gregorio.Arvilla@epvgroup.com> writes:

> I regret to say that I have not been able to compile xsd on
> a HP-UX 11.00 machine. I don't have a lot of experince on
> UNIX environments and I'm learning everything I can about them.

Building XSD can be quite involving especially on older UNIX systems
without GNU tools (gcc, make, etc.), like HP-UX 11.00.


> The project requires that I use the aCC compiler and the
> Korn shell.

Your project probably requires that you use aCC to build *your*
code. It does not really matter what the XSD compiler itself is
built with. I don't think you will be able to build XSD using aCC3
that comes on PA-RISC systems (you might be able to do that with
aCC6 which comes on IA-64). So the idea here is to build the compiler
using GCC and compile the generated code with aCC.


> I followed the build instructions from
> http://www.codesynthesis.com/projects/xsd/extras/build-unix.xhtml.
> I have not even been able to compile the first package, build-0.2.2.tar.bz2,
> this is what I get:
>
> # make install install_prefix=/users/greg/xsd_codeSynthesis/build-0.2.2
> Make: Cannot read or get .  Stop.

You need GNU make (besides other GNU tools) which is covered in the
"Prerequisites" section of the instructions you refer above.

I think at this point it will be much easier for you to compile your
schemas on a different box (e.g., Windows) and simply move them to
HP-UX.


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/20070123/07f46d77/attachment.pgp
From Gregorio.Arvilla at epvgroup.com  Tue Jan 23 15:30:58 2007
From: Gregorio.Arvilla at epvgroup.com (Gregorio Arvilla)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] Question about xsd
In-Reply-To: <20070123200423.GA3095@karelia>
Message-ID: <H000006e00128571.1169584258.mailx.epvgroup.com@MHS>

Hello Boris,

If I generate code for a xsd schema on a Windows machine and then
move that generated code to the HP-UX machine, what do I need to
install on the HP-UX machine to use that code?

Gregorio





-----Original Message-----
From: Boris Kolpackov [mailto:boris@codesynthesis.com]
Sent: Tuesday, January 23, 2007 1:04 PM
To: Gregorio Arvilla
Cc: xsd-users
Subject: Re: [xsd-users] Question about xsd


Hi Gregorio,

Gregorio Arvilla <Gregorio.Arvilla@epvgroup.com> writes:

> I regret to say that I have not been able to compile xsd on
> a HP-UX 11.00 machine. I don't have a lot of experince on
> UNIX environments and I'm learning everything I can about them.

Building XSD can be quite involving especially on older UNIX systems
without GNU tools (gcc, make, etc.), like HP-UX 11.00.


> The project requires that I use the aCC compiler and the
> Korn shell.

Your project probably requires that you use aCC to build *your*
code. It does not really matter what the XSD compiler itself is
built with. I don't think you will be able to build XSD using aCC3
that comes on PA-RISC systems (you might be able to do that with
aCC6 which comes on IA-64). So the idea here is to build the compiler
using GCC and compile the generated code with aCC.


> I followed the build instructions from
> http://www.codesynthesis.com/projects/xsd/extras/build-unix.xhtml.
> I have not even been able to compile the first package, build-0.2.2.tar.bz2,
> this is what I get:
>
> # make install install_prefix=/users/greg/xsd_codeSynthesis/build-0.2.2
> Make: Cannot read or get .  Stop.

You need GNU make (besides other GNU tools) which is covered in the
"Prerequisites" section of the instructions you refer above.

I think at this point it will be much easier for you to compile your
schemas on a different box (e.g., Windows) and simply move them to
HP-UX.


hth,
-boris


From boris at codesynthesis.com  Tue Jan 23 16:11:51 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] Question about xsd
In-Reply-To: <H000006e00128571.1169584258.mailx.epvgroup.com@MHS>
References: <20070123200423.GA3095@karelia>
	<H000006e00128571.1169584258.mailx.epvgroup.com@MHS>
Message-ID: <20070123211151.GA3218@karelia>

Hi Gregorio,

Gregorio Arvilla <Gregorio.Arvilla@epvgroup.com> writes:

> If I generate code for a xsd schema on a Windows machine and then
> move that generated code to the HP-UX machine, what do I need to
> install on the HP-UX machine to use that code?

You will need two things besides the generated code:

1. Xerces-C++. Compile it using aCC. Note that to build Xerces-C++
   you will also need GNU make. Check is you have 'gmake' command
   on you system. If so then that's GNU make. If not then you will
   need to build or get one. Once you have GNU make, you can do:

   $ gzip -d xerces-c-src_2_7_0.tar.gz
   $ tar xf xerces-c-src_2_7_0.tar
   $ cd xerces-c-src_2_7_0
   $ export XERCESCROOT=`pwd`
   $ cd src/xercesc
   $ ./runConfigure -p hp-11 -x aCC
   $ gmake

   Run runConfigure without any options to see the complete
   list of the configuration parameters. At the end of the
   build headers will be in xerces-c-src_2_7_0/include and
   libraries in xerces-c-src_2_7_0/lib


2. Libxsd. This is header-only XSD run-time library. You can
   copy it along with the generated code from the Windows box.
   You don't need to build it.


After that you are all set. For instance, the hello example
that comes with the XSD distribution can be compiled like
so:

$ aCC -AA -Ixerces-c-src_2_7_0/include -Ilibxsd -Lxerces-c-src_2_7_0/lib hello.cxx driver.cxx -lxerces-c


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/20070123/f0a615ae/attachment.pgp
From jerome.dumesnil at gmail.com  Tue Jan 23 16:26:06 2007
From: jerome.dumesnil at gmail.com (=?ISO-8859-1?Q?J=E9r=F4me_Dumesnil?=)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] Issue with includes
In-Reply-To: <20070121170406.GA20900@karelia>
References: <50f8db60701210642s5d00d4d0w15a4ba1edd0ad31e@mail.gmail.com>
	<20070121170406.GA20900@karelia>
Message-ID: <50f8db60701231326p619eb3f2lf4875287993eed28@mail.gmail.com>

Hi Boris

2007/1/21, Boris Kolpackov <boris@codesynthesis.com>:
>
> Hi J?r?me,
>
> J?r?me Dumesnil <jerome.dumesnil@gmail.com> writes:
>
>
> > As you said, I modified x3d-3.0.xsd to include
> > x3d-3.0-Web3dExtensionsPublic.xsd.
>
> It is the other way around: modify x3d-3.0-Web3dExtensionsPublic.xsd to
> include x3d-3.0.xsd.


Oh , yes !! I made a mistake when wrote this.
I well modified x3d-3.0-Web3dExtensionsPublic.xsd to include include
x3d-3.0.xsd

> So I generate sources files with :
> >
> > xsd cxx-tree --morph-anonymous --root-element X3D --hxx-suffix .h
> > --cxx-suffix .cpp --output-dir src/ x3d-3.0.xsd
> > xsd cxx-tree --morph-anonymous --root-element X3D --hxx-suffix .h
> > --cxx-suffix .cpp --output-dir src/ x3d-3.0-Web3dExtensionsPublic.xsd
> > xsd cxx-tree --morph-anonymous --root-element X3D --hxx-suffix .h
> > --cxx-suffix .cpp --output-dir src/ x3d-3.0-Web3dExtensionsPublic.xsd
> >
> > And after, I moved to src directory and I compiled them with :
> > gcc -c x3d-3.0.cpp
>
> I just tried these exact options and it works fine for me with both
> gcc 3.3.6 and 4.1.2. I assume you are using a recent version of
> XSD (e.g., 3.2.0 or 3.2.1.b2).


I used  CodeSynthesis xsd program version 2.3.0 and x3d's xsd files version
3.0.0
I (hardly) found the version 3.1.0 for x3d's xsd files but not the versions
3.2.0 or 3.2.1.b2.
The version 3.1.0 does the same errors I mentionned before when I compil
with gcc.

So, can you tell me where (and how) did you found the versions 3.2.0 or
3.2.1.b2) ??

Thank you, JayDee

From boris at codesynthesis.com  Tue Jan 23 16:33:19 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] Issue with includes
In-Reply-To: <50f8db60701231326p619eb3f2lf4875287993eed28@mail.gmail.com>
References: <50f8db60701210642s5d00d4d0w15a4ba1edd0ad31e@mail.gmail.com>
	<20070121170406.GA20900@karelia>
	<50f8db60701231326p619eb3f2lf4875287993eed28@mail.gmail.com>
Message-ID: <20070123213319.GB3218@karelia>

Hi J?r?me,

J?r?me Dumesnil <jerome.dumesnil@gmail.com> writes:

> I used  CodeSynthesis xsd program version 2.3.0 and x3d's xsd files version
> 3.0.0
> I (hardly) found the version 3.1.0 for x3d's xsd files but not the versions
> 3.2.0 or 3.2.1.b2.

I meant XSD 2.3.0 or 2.3.1.b2, not X3D 3.2.0 or 3.2.1.b2.


> The version 3.1.0 does the same errors I mentionned before when I compil
> with gcc.

Here is my modified version of X3D 3.0 schemas:

http://codesynthesis.com/~boris/tmp/x3d-3.0-mod.tar.gz


Can you also download XSD 2.3.1 (released today) and try to compile the
above schemas?


BTW, you are using gcc 4.1.1, right?


-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/20070123/36febfec/attachment.pgp
From jerome.dumesnil at gmail.com  Tue Jan 23 17:11:26 2007
From: jerome.dumesnil at gmail.com (JayDee)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] Issue with includes
In-Reply-To: <20070123213319.GB3218@karelia>
References: <50f8db60701210642s5d00d4d0w15a4ba1edd0ad31e@mail.gmail.com>
	<20070121170406.GA20900@karelia>
	<50f8db60701231326p619eb3f2lf4875287993eed28@mail.gmail.com>
	<20070123213319.GB3218@karelia>
Message-ID: <50f8db60701231411q333e36cfqa8ab72856cb6377e@mail.gmail.com>

2007/1/23, Boris Kolpackov <boris@codesynthesis.com>:
>
> Hi J?r?me,
>
> J?r?me Dumesnil <jerome.dumesnil@gmail.com> writes:
>
> > I used  CodeSynthesis xsd program version 2.3.0 and x3d's xsd files
> version
> > 3.0.0
> > I (hardly) found the version 3.1.0 for x3d's xsd files but not the
> versions
> > 3.2.0 or 3.2.1.b2.
>
> I meant XSD 2.3.0 or 2.3.1.b2, not X3D 3.2.0 or 3.2.1.b2.


OK

> The version 3.1.0 does the same errors I mentionned before when I compil
> > with gcc.
>
> Here is my modified version of X3D 3.0 schemas:
>
> http://codesynthesis.com/~boris/tmp/x3d-3.0-mod.tar.gz


I tried to compil your shemas with XSD 2.3.0, and I get the sames errors
with gcc :
x3d-3.0-Web3dExtensionsPublic.h:277: erreur: 'IS' in namespace '::' does not
name a type
x3d-3.0-Web3dExtensionsPublic.h:278: erreur: 'type' was not declared in this
scope
x3d-3.0-Web3dExtensionsPublic.h:278: erreur: patron de l'argument 1 est
invalide
x3d-3.0-Web3dExtensionsPublic.h:279: erreur: 'type' was not declared in this
scope
x3d-3.0-Web3dExtensionsPublic.h:279: erreur: patron de l'argument 1 est
invalide
x3d-3.0-Web3dExtensionsPublic.h:279: erreur: patron de l'argument 2 est
invalide
x3d-3.0-Web3dExtensionsPublic.h:289: erreur: expected unqualified-id before
'&' token
x3d-3.0-Web3dExtensionsPublic.h:289: erreur: expected ',' or '...' before
'&' token
x3d-3.0-Web3dExtensionsPublic.h:289: erreur: ISO C++ forbids declaration of
'parameter' with no type
x3d-3.0-Web3dExtensionsPublic.h:295: erreur: 'type' is not a member of
'XvlShell::IS'

Can you also download XSD 2.3.1 (released today) and try to compile the
> above schemas?


The three cpp files compils without any problems with XSD 2.3.1.
Thank you for your help !!!

BTW, you are using gcc 4.1.1, right?


Yes

From Gregorio.Arvilla at epvgroup.com  Tue Jan 23 17:26:12 2007
From: Gregorio.Arvilla at epvgroup.com (Gregorio Arvilla)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] Question about xsd
In-Reply-To: <20070123211151.GA3218@karelia>
Message-ID: <H000006e00128894.1169591171.mailx.epvgroup.com@MHS>


Hi Boris,

I did what you said below. Here is the command that I'm using:

[/users/greg/xsd_codeSynthesis/xsd-2.3.1-hppa-hpux/examples/cxx/tree/hello]
[bilbo][greg] aCC -AA -I../../../../../xerces-c-src_2_7_0/include -I../../../../libxsd -Lxerces-c-src_2_7_0/lib hello.cxx driver.cxx -lxerces-c


And here are some of the first few lines of the errors I'm getting:


[/users/greg/xsd_codeSynthesis/xsd-2.3.1-hppa-hpux/examples/cxx/tree/hello]
[bilbo][greg] aCC -AA -I../../../../../xerces-c-src_2_7_0/include -I../../../../libxsd -Lxerces-c-src_2_7_0/lib hello.cxx driver.cxx -lxerces-c
hello.cxx:
Warning 930: "../../../../../xerces-c-src_2_7_0/include/xercesc/util/PlatformUtils.hpp", line 793 # Placement operator delete invocation is not yet implemented.
    MakeXMLException(XMLPlatformUtilsException, XMLUTIL_EXPORT)
    ^^^^^^^^^^^^^^^^
Warning 930: "../../../../../xerces-c-src_2_7_0/include/xercesc/util/ArrayIndexOutOfBoundsException.hpp", line 28 # Placement operator delete invocation is not yet implemented.
    MakeXMLException(ArrayIndexOutOfBoundsException, XMLUTIL_EXPORT)
    ^^^^^^^^^^^^^^^^
Error 331: "../../../../libxsd/xsd/cxx/tree/containers.hxx", line 395 # Illegal cast expression; cannot cast expression type '<no type>' to 'bool'.
          template <typename X, bool fund = fundamental_p<X>::r>
                                            ^^^^^^^^^^^^^^^^^^^
Error 556: "../../../../libxsd/xsd/cxx/tree/list.hxx", line 34 # Unable to generate specialization class sequence<#1,(bool)xsd::cxx::tree::fundamental_p::r> due to errors during generation.
          class list<X, C, false>: public sequence<X>
                                          ^^^^^^^^^^^
Error 331: "../../../../libxsd/xsd/cxx/tree/containers.hxx", line 395 # Illegal cast expression; cannot cast expression type '<no type>' to 'bool'.
          template <typename X, bool fund = fundamental_p<X>::r>
                                            ^^^^^^^^^^^^^^^^^^^
Error 556: "../../../../libxsd/xsd/cxx/tree/list.hxx", line 44 # Unable to generate specialization class sequence<#1,(bool)xsd::cxx::tree::fundamental_p::r> due to errors during generation.
            list (typename sequence<X>::size_type n)
                           ^^^^^^^^^^^
Error 331: "../../../../libxsd/xsd/cxx/tree/containers.hxx", line 395 # Illegal cast expression; cannot cast expression type '<no type>' to 'bool'.
          template <typename X, bool fund = fundamental_p<X>::r>
                                            ^^^^^^^^^^^^^^^^^^^
Error 556: "../../../../libxsd/xsd/cxx/tree/list.hxx", line 49 # Unable to generate specialization class sequence<#1,(bool)xsd::cxx::tree::fundamental_p::r> due to errors during generation.
            list (typename sequence<X>::size_type n, const X& x)
                           ^^^^^^^^^^^
Error 331: "../../../../libxsd/xsd/cxx/tree/containers.hxx", line 395 # Illegal cast expression; cannot cast expression type '<no type>' to 'bool'.
          template <typename X, bool fund = fundamental_p<X>::r>
                                            ^^^^^^^^^^^^^^^^^^^
Error 556: "../../../../libxsd/xsd/cxx/tree/list.hxx", line 45 # Unable to generate specialization class sequence<#1,(bool)xsd::cxx::tree::fundamental_p::r> due to errors during generation.
                : sequence<X> (n, X ())
                  ^^^^^^^^^^^
Error 331: "../../../../libxsd/xsd/cxx/tree/containers.hxx", line 395 # Illegal cast expression; cannot cast expression type '<no type>' to 'bool'.
          template <typename X, bool fund = fundamental_p<X>::r>
                                            ^^^^^^^^^^^^^^^^^^^
Error 556: "../../../../libxsd/xsd/cxx/tree/list.hxx", line 50 # Unable to generate specialization class sequence<#1,(bool)xsd::cxx::tree::fundamental_p::r> due to errors during generation.
                : sequence<X> (n, x)
                  ^^^^^^^^^^^
Error 331: "../../../../libxsd/xsd/cxx/tree/containers.hxx", line 395 # Illegal cast expression; cannot cast expression type '<no type>' to 'bool'.
          template <typename X, bool fund = fundamental_p<X>::r>
                                            ^^^^^^^^^^^^^^^^^^^
Error 556: "../../../../libxsd/xsd/cxx/tree/list.hxx", line 56 # Unable to generate specialization class sequence<#1,(bool)xsd::cxx::tree::fundamental_p::r> due to errors during generation.
                : sequence<X> (b, e)
                  ^^^^^^^^^^^



I would really appreciate your help.

Thank you

Gregorio






-----Original Message-----
From: Boris Kolpackov [mailto:boris@codesynthesis.com]
Sent: Tuesday, January 23, 2007 2:12 PM
To: Gregorio Arvilla
Cc: xsd-users
Subject: Re: [xsd-users] Question about xsd


Hi Gregorio,

Gregorio Arvilla <Gregorio.Arvilla@epvgroup.com> writes:

> If I generate code for a xsd schema on a Windows machine and then
> move that generated code to the HP-UX machine, what do I need to
> install on the HP-UX machine to use that code?

You will need two things besides the generated code:

1. Xerces-C++. Compile it using aCC. Note that to build Xerces-C++
   you will also need GNU make. Check is you have 'gmake' command
   on you system. If so then that's GNU make. If not then you will
   need to build or get one. Once you have GNU make, you can do:

   $ gzip -d xerces-c-src_2_7_0.tar.gz
   $ tar xf xerces-c-src_2_7_0.tar
   $ cd xerces-c-src_2_7_0
   $ export XERCESCROOT=`pwd`
   $ cd src/xercesc
   $ ./runConfigure -p hp-11 -x aCC
   $ gmake

   Run runConfigure without any options to see the complete
   list of the configuration parameters. At the end of the
   build headers will be in xerces-c-src_2_7_0/include and
   libraries in xerces-c-src_2_7_0/lib


2. Libxsd. This is header-only XSD run-time library. You can
   copy it along with the generated code from the Windows box.
   You don't need to build it.


After that you are all set. For instance, the hello example
that comes with the XSD distribution can be compiled like
so:

$ aCC -AA -Ixerces-c-src_2_7_0/include -Ilibxsd -Lxerces-c-src_2_7_0/lib hello.cxx driver.cxx -lxerces-c


hth,
-boris


From Gregorio.Arvilla at epvgroup.com  Tue Jan 23 18:09:16 2007
From: Gregorio.Arvilla at epvgroup.com (Gregorio Arvilla)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] Question about xsd
In-Reply-To: <20070123211151.GA3218@karelia>
Message-ID: <H000006e001289a1.1169593755.mailx.epvgroup.com@MHS>

Hi Boris,

Please ignore the previous message, the one about the compiler errors.
I used a cast to bool and it seems to work. Now I would like to ask
you about something else. When I try to run the executable this is
what I get:

[/users/greg/xsd_codeSynthesis/xsd-2.3.1-hppa-hpux/examples/cxx/tree/hello]
[bilbo][greg] ./a.out
/usr/lib/dld.sl: Unresolved symbol: typeid__XT9exception_ (data)  from ../../../../../xerces-c-src_2_7_0/lib/libxerces-c.sl.27
Abort(coredump)

Thank you

Gregorio




-----Original Message-----
From: Boris Kolpackov [mailto:boris@codesynthesis.com]
Sent: Tuesday, January 23, 2007 2:12 PM
To: Gregorio Arvilla
Cc: xsd-users
Subject: Re: [xsd-users] Question about xsd


Hi Gregorio,

Gregorio Arvilla <Gregorio.Arvilla@epvgroup.com> writes:

> If I generate code for a xsd schema on a Windows machine and then
> move that generated code to the HP-UX machine, what do I need to
> install on the HP-UX machine to use that code?

You will need two things besides the generated code:

1. Xerces-C++. Compile it using aCC. Note that to build Xerces-C++
   you will also need GNU make. Check is you have 'gmake' command
   on you system. If so then that's GNU make. If not then you will
   need to build or get one. Once you have GNU make, you can do:

   $ gzip -d xerces-c-src_2_7_0.tar.gz
   $ tar xf xerces-c-src_2_7_0.tar
   $ cd xerces-c-src_2_7_0
   $ export XERCESCROOT=`pwd`
   $ cd src/xercesc
   $ ./runConfigure -p hp-11 -x aCC
   $ gmake

   Run runConfigure without any options to see the complete
   list of the configuration parameters. At the end of the
   build headers will be in xerces-c-src_2_7_0/include and
   libraries in xerces-c-src_2_7_0/lib


2. Libxsd. This is header-only XSD run-time library. You can
   copy it along with the generated code from the Windows box.
   You don't need to build it.


After that you are all set. For instance, the hello example
that comes with the XSD distribution can be compiled like
so:

$ aCC -AA -Ixerces-c-src_2_7_0/include -Ilibxsd -Lxerces-c-src_2_7_0/lib hello.cxx driver.cxx -lxerces-c


hth,
-boris


From lee at dininfo.com  Tue Jan 23 19:04:01 2007
From: lee at dininfo.com (lee)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] Fixed: "Unknown element 'hello'"
Message-ID: <001001c73f4b$27590130$0200000a@dininfo4dc7216>

Bad schema path.
  ----- Original Message ----- 
  From: lee 
  To: xsd-users@codesynthesis.com 
  Sent: Tuesday, January 23, 2007 5:28 PM
  Subject: "Unknown element 'hello'"


  Although I can run the "hello" sample just fine, when I copy/paste the same code into my project, I receive the following error messages:

  "Unknown element 'hello'"
  "Attribute '{http://www.w3.org/2000/xmlns/}xsi' is not declared for element 'hello'"
  "Attribute '{http://www.w3.org/2001/XMLSchema-instance}noNamespaceSchemaLocation' is not declared for element 'hello'" 
  "Unknown element 'greeting'" 
  "Unknown element 'name'" 
  "Unknown element 'name'" 
  "Unknown element 'name'" 


  Any help would be appreciated.

  XML Schema Definition Compiler 2.3.1
  Microsoft Visual Studio 2005
  Version 8.0.50727.42

From lee at dininfo.com  Tue Jan 23 18:28:01 2007
From: lee at dininfo.com (lee)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] "Unknown element 'hello'"
Message-ID: <001d01c73f46$1fa2c4d0$0200000a@dininfo4dc7216>

Although I can run the "hello" sample just fine, when I copy/paste the same code into my project, I receive the following error messages:

"Unknown element 'hello'"
"Attribute '{http://www.w3.org/2000/xmlns/}xsi' is not declared for element 'hello'"
"Attribute '{http://www.w3.org/2001/XMLSchema-instance}noNamespaceSchemaLocation' is not declared for element 'hello'" 
"Unknown element 'greeting'" 
"Unknown element 'name'" 
"Unknown element 'name'" 
"Unknown element 'name'" 


Any help would be appreciated.

XML Schema Definition Compiler 2.3.1
Microsoft Visual Studio 2005
Version 8.0.50727.42

From boris at codesynthesis.com  Wed Jan 24 01:56:45 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] Fixed: "Unknown element 'hello'"
In-Reply-To: <001001c73f4b$27590130$0200000a@dininfo4dc7216>
References: <001001c73f4b$27590130$0200000a@dininfo4dc7216>
Message-ID: <20070124065645.GA4332@karelia>

Hi,

lee <lee@dininfo.com> writes:

> Bad schema path.

That's right. The following FAQ entry discusses a number of ways
to address this:

http://www.codesynthesis.com/projects/xsd/documentation/cxx/tree/faq/#2.1


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/20070124/5b18c660/attachment.pgp
From boris at codesynthesis.com  Wed Jan 24 10:48:05 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] Question about xsd
In-Reply-To: <H000006e001289a1.1169593755.mailx.epvgroup.com@MHS>
References: <20070123211151.GA3218@karelia>
	<H000006e001289a1.1169593755.mailx.epvgroup.com@MHS>
Message-ID: <20070124154805.GC5427@karelia>

Hi Gregorio,

Gregorio Arvilla <Gregorio.Arvilla@epvgroup.com> writes:

> Please ignore the previous message, the one about the compiler errors.

Great, so you've managed to build the executable. How did you resolve
these compile errors? Also which version of aCC are you using (run
aCC -V to find out)?


> Now I would like to ask you about something else. When I try to run
> the executable this is what I get:
>
> [/users/greg/xsd_codeSynthesis/xsd-2.3.1-hppa-hpux/examples/cxx/tree/hello]
> [bilbo][greg] ./a.out
> /usr/lib/dld.sl: Unresolved symbol: typeid__XT9exception_ (data)  from ../../../../../xerces-c-src_2_7_0/lib/libxerces-c.sl.27

Hm, never seen anything like this. A little bit of googling revealed[1]
that you need to make sure Xerces-C++ is build with the -AA option. Can
you try to reconfigure and recompile it with this command:

$ ./runConfigure -p hp-11 -x aCC -l -AA -z -AA


[1] http://www.oracle.com/technology/documentation/berkeley-db/xml/ref_xml/xml_unix/hpux.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/20070124/8dc83417/attachment.pgp
From Gregorio.Arvilla at epvgroup.com  Wed Jan 24 18:35:38 2007
From: Gregorio.Arvilla at epvgroup.com (Gregorio Arvilla)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] Question about xsd
In-Reply-To: <20070124154805.GC5427@karelia>
Message-ID: <H000006e0012a278.1169681738.mailx.epvgroup.com@MHS>

Hello Boris,

The aCC version that I'm using is: aCC: HP ANSI C++ B3910B A.03.37

I finally got passed the Unresolved symbol error when executing the a.out.
I'm at another obstacle, this is what I get when I run it now:

[/users/greg/xsd_codeSynthesis/xsd-2.3.1-hppa-hpux/examples/cxx/tree/hello]
[bilbo][greg] ./a.out hello.xml
Memory fault(coredump)


I used the wdb HP-UX debugger and did a print of the stack:

0  0x77332884 in pthread_mutex_destroy+0x18 () from /usr/lib/libpthread.1
#1  0x77fc0900 in __thread_mutex_free+0x40 () from /usr/lib/libc.2
#2  0x77d313cc in _HPMutexWrapper::~_HPMutexWrapper+0x34 () from /usr/lib/libstd_v2.2
#3  0x1840c in std::basic_string<char,std::char_traits<char>,std::allocator<char>>::_C_unlink (this=0x77ff2670) at /opt/aCC/include_std/string:1002
#4  0x18238 in std::basic_string<char,std::char_traits<char>,std::allocator<char>>::~basic_string<char,std::char_traits<char>,std::allocator<char>> (this=0x77ff2670, #free=2) at /opt/aCC/include_std/string:361
#5  0x1ceb8 in hello_type::parse (this=0x400452c8, e=@0x40099278, f={, , , , , }) at /users/greg/xsd_codeSynthesis/xsd-2.3.1-hppa-hpux/examples/cxx/tree/hello/hello.cxx:136
#6  0x1c750 in hello_type::hello_type () at /users/greg/xsd_codeSynthesis/xsd-2.3.1-hppa-hpux/examples/cxx/tree/hello/hello.cxx:126
#7  0x2a1a8 in hello (#aggretxform#1271=@0x77ff2440, d=@0x4002d730, f={, , , , , }, No.Identifier=@0x77ff2434) at /users/greg/xsd_codeSynthesis/xsd-2.3.1-hppa-hpux/examples/cxx/tree/hello/hello.cxx:407
#8  0x24540 in hello (#aggretxform#1008=@0x77ff2328, u=@0x77ff2324, f={, , , , , }, p=@0x77ff231c) at /users/greg/xsd_codeSynthesis/xsd-2.3.1-hppa-hpux/examples/cxx/tree/hello/hello.cxx:209
#9  0x36c24 in main (argc=2, argv=0x77ff1f0c) at /users/greg/xsd_codeSynthesis/xsd-2.3.1-hppa-hpux/examples/cxx/tree/hello/driver.cxx:25


Stepping thru the code, it always crashes on line 136 of the hello.cxx file, here is the line:

const ::xsd::cxx::xml::dom::element< char > e (p.next_element ());

This line seems to somehow call the destructor of the basic_string class (or template).

Thanks you


Gregorio


-----Original Message-----
From: Boris Kolpackov [mailto:boris@codesynthesis.com]
Sent: Wednesday, January 24, 2007 8:48 AM
To: Gregorio Arvilla
Cc: xsd-users
Subject: Re: [xsd-users] Question about xsd


Hi Gregorio,

Gregorio Arvilla <Gregorio.Arvilla@epvgroup.com> writes:

> Please ignore the previous message, the one about the compiler errors.

Great, so you've managed to build the executable. How did you resolve
these compile errors? Also which version of aCC are you using (run
aCC -V to find out)?


> Now I would like to ask you about something else. When I try to run
> the executable this is what I get:
>
> [/users/greg/xsd_codeSynthesis/xsd-2.3.1-hppa-hpux/examples/cxx/tree/hello]
> [bilbo][greg] ./a.out
> /usr/lib/dld.sl: Unresolved symbol: typeid__XT9exception_ (data)  from ../../../../../xerces-c-src_2_7_0/lib/libxerces-c.sl.27

Hm, never seen anything like this. A little bit of googling revealed[1]
that you need to make sure Xerces-C++ is build with the -AA option. Can
you try to reconfigure and recompile it with this command:

$ ./runConfigure -p hp-11 -x aCC -l -AA -z -AA


[1] http://www.oracle.com/technology/documentation/berkeley-db/xml/ref_xml/xml_unix/hpux.html


hth,
-boris


From mhoffm1060 at aol.com  Wed Jan 24 18:33:25 2007
From: mhoffm1060 at aol.com (mhoffm1060@aol.com)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] base64Binary default value segfaults on startup
Message-ID: <8C90E272DEF2B36-D84-9936@mblk-d40.sysops.aol.com>

The problem I'm having is when a default value is added to the optional attribute ( "problem" below ), the program crashes on startup.  However when I remove the default value, the program runs fine.  ( The schema is defined by another entity, so just removing it is not a solution for me ). 
 
It looks like the problem is that XMLPlatformUtils::Initialize() is not being called before XMLString::transcode().
 
Thanks,
Mark Hoffmann
 
platform:     linux
xsd version:  2.3.0
gcc version:  4.1.0
 
Here is a fragment of the schema:
 
<xs:simpleType name="bar">
    <xs:restriction base="xs:base64Binary">
        <xs:maxLength value="1024">
        <xs:minLength value="0">
    </xs:restriction>
</xs:simpleType>
...
<xs:attributeGroup name="foo">
    ...
    <xs:attribute name="problem" type="bar" use="optional" default=""/>
    ...
</xs:attributeGroup>
 
 
The generated code:
 
const foo::problem::type foo::problem::default_value_(
    ::std::basic_string< char > (""), 0, 0, 0 );
 
 
Stack trace:
transcode                     xercesc_2_7::XMLString
    no code.
 
transcode_to_xmlch<char>      xsd::cxx::xml
  xsd/cxx/xml/string.ixx line 64
    template<>
    inline XMLCh*
    transcode_to_xmlch( const std::basic_string<char>& s)
    {
->        return xercesc::XMLString::transcode (s.c_str ());
    }
 
string<char>
  xsd/cxx/xml/string.hxx line 49
    template <typename C>
    string (const std::basic_string<C>& s)
->      : s_ (transcode_to_xmlch<C> (s))
    {
    }
 
base64_binary
  xsd/cxx/tree/parsing.txx  line 673
    template <typename C, typename B>
    base64_binary<C, B>::
    base64_binary ( const std::basic_string<C>& s,
                    const xercesc::DOMElement* e,
                    flags f,
                    type* c)
        : B (s, e, f, c)
    {
->    decode (xml::string (s).c_str ());
    }
 
bar
    bar::
    bar (const ::std::basic_string< char >& s,
         const ::xercesc::DOMElement* e,
         ::xml_schema::flags f,
         ::xml_schema::type* c)
->  : ::xml_schema::base64_binary (s, e, f, c)
    {
    }
 
_static_initialization_and_destruction_...
    const foo::problem::type foo::problem::default_value_ (
->    ::std::basic_string< char > (""), 0, 0, 0);
________________________________________________________________________
Check out the new AOL.  Most comprehensive set of free safety and security tools, free access to millions of high-quality videos from across the web, free AOL Mail and more.

From boris at codesynthesis.com  Thu Jan 25 03:14:56 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] base64Binary default value segfaults on startup
In-Reply-To: <8C90E272DEF2B36-D84-9936@mblk-d40.sysops.aol.com>
References: <8C90E272DEF2B36-D84-9936@mblk-d40.sysops.aol.com>
Message-ID: <20070125081456.GA7520@karelia>

Hi Mark,

mhoffm1060@aol.com <mhoffm1060@aol.com> writes:

> The problem I'm having is when a default value is added to the optional
> attribute ( "problem" below ), the program crashes on startup.  However
> when I remove the default value, the program runs fine.  ( The schema
> is defined by another entity, so just removing it is not a solution
> for me ).
>
> It looks like the problem is that XMLPlatformUtils::Initialize() is
> not being called before XMLString::transcode().

Yes, I believe you are right. I suggest that you upgrade to 3.2.1
where we moved away from XMLString::transcode. I think that should
solve your problem. And thanks for reporting this!


-boris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 652 bytes
Desc: Digital signature
Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070125/69f3d29a/attachment.pgp
From boris at codesynthesis.com  Thu Jan 25 03:22:03 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] Question about xsd
In-Reply-To: <H000006e0012a278.1169681738.mailx.epvgroup.com@MHS>
References: <20070124154805.GC5427@karelia>
	<H000006e0012a278.1169681738.mailx.epvgroup.com@MHS>
Message-ID: <20070125082203.GB7520@karelia>

Hi Gregorio,

Gregorio Arvilla <Gregorio.Arvilla@epvgroup.com> writes:

> The aCC version that I'm using is: aCC: HP ANSI C++ B3910B A.03.37

Thanks for letting me know.


> [/users/greg/xsd_codeSynthesis/xsd-2.3.1-hppa-hpux/examples/cxx/tree/hello]
> [bilbo][greg] ./a.out hello.xml
> Memory fault(coredump)
>
>
> I used the wdb HP-UX debugger and did a print of the stack:
>
> 0  0x77332884 in pthread_mutex_destroy+0x18 () from /usr/lib/libpthread.1

I think this is the same problem as discussed in this message:

http://www.codesynthesis.com/pipermail/xsd-users/2006-October/000583.html

In short, you will need to recompile and relink hello.cxx and driver.cxx
with the -mt option. Alternatively, you can rebuild Xerces-C++ with
threading disabled ('-r none' option to runConfigure).


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/20070125/944612a8/attachment.pgp
From mhoffm1060 at aol.com  Thu Jan 25 12:54:36 2007
From: mhoffm1060 at aol.com (mhoffm1060@aol.com)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] base64Binary default value segfaults on startup
In-Reply-To: <20070125081456.GA7520@karelia>
References: <8C90E272DEF2B36-D84-9936@mblk-d40.sysops.aol.com>
	<20070125081456.GA7520@karelia>
Message-ID: <8C90EC102D612B9-FD0-6347@mblk-d49.sysops.aol.com>

Hi Boris,
Thanks for your quick response.
 
I just finished upgrading XSD, and everything is working.
 
Thanks for your help.
 
Mark
 
 
 
-----Original Message-----
From: boris@codesynthesis.com
To: mhoffm1060@aol.com
Cc: xsd-users@codesynthesis.com
Sent: Thu, 25 Jan 2007 12:14 AM
Subject: Re: [xsd-users] base64Binary default value segfaults on startup


Hi Mark,

mhoffm1060@aol.com <mhoffm1060@aol.com> writes:

> The problem I'm having is when a default value is added to the optional
> attribute ( "problem" below ), the program crashes on startup.  However
> when I remove the default value, the program runs fine.  ( The schema
> is defined by another entity, so just removing it is not a solution
> for me ).
>
> It looks like the problem is that XMLPlatformUtils::Initialize() is
> not being called before XMLString::transcode().

Yes, I believe you are right. I suggest that you upgrade to 3.2.1
where we moved away from XMLString::transcode. I think that should
solve your problem. And thanks for reporting this!


-boris
________________________________________________________________________
Check out the new AOL.  Most comprehensive set of free safety and security tools, free access to millions of high-quality videos from across the web, free AOL Mail and more.

From Gregorio.Arvilla at epvgroup.com  Fri Jan 26 12:30:18 2007
From: Gregorio.Arvilla at epvgroup.com (Gregorio Arvilla)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] Question about xsd
In-Reply-To: <20070125082203.GB7520@karelia>
Message-ID: <H000006e0012c9f4.1169832617.mailx.epvgroup.com@MHS>

Hello Boris,

It is finally working. Here is an example:

[/users/greg/xsd_codeSynthesis/xsd-2.3.1-hppa-hpux/examples/cxx/tree/hello]
[bilbo][greg] ./driver hello.xml
Hello, sun!
Hello, moon!
Hello, world!

I created a makefile for the HP-UX version of make to build this example 
and a change I had to make was to add -AA and -lstd_v2 to the linker, otherwise 
it would give me a lot of unresolved symbols.

Thank you very much for all your help!!!!

Gregorio



-----Original Message-----
From: Boris Kolpackov [mailto:boris@codesynthesis.com]
Sent: Thursday, January 25, 2007 1:22 AM
To: Gregorio Arvilla
Cc: xsd-users
Subject: Re: [xsd-users] Question about xsd


Hi Gregorio,

Gregorio Arvilla <Gregorio.Arvilla@epvgroup.com> writes:

> The aCC version that I'm using is: aCC: HP ANSI C++ B3910B A.03.37

Thanks for letting me know.


> [/users/greg/xsd_codeSynthesis/xsd-2.3.1-hppa-hpux/examples/cxx/tree/hello]
> [bilbo][greg] ./a.out hello.xml
> Memory fault(coredump)
>
>
> I used the wdb HP-UX debugger and did a print of the stack:
>
> 0  0x77332884 in pthread_mutex_destroy+0x18 () from /usr/lib/libpthread.1

I think this is the same problem as discussed in this message:

http://www.codesynthesis.com/pipermail/xsd-users/2006-October/000583.html

In short, you will need to recompile and relink hello.cxx and driver.cxx
with the -mt option. Alternatively, you can rebuild Xerces-C++ with
threading disabled ('-r none' option to runConfigure).


hth,
-boris


From Gregorio.Arvilla at epvgroup.com  Fri Jan 26 16:23:41 2007
From: Gregorio.Arvilla at epvgroup.com (Gregorio Arvilla)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] Question about xsd
In-Reply-To: <20070125082203.GB7520@karelia>
Message-ID: <H000006e0012cfa1.1169846620.mailx.epvgroup.com@MHS>

Hello Boris,

I have a question about xsd. How do I create an empty instance of the
xsd generated code and fill it with data myself (instead of the data coming
from an xml file)?

Thank you

Gregorio


From boris at codesynthesis.com  Sat Jan 27 14:35:43 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] Question about xsd
In-Reply-To: <H000006e0012cfa1.1169846620.mailx.epvgroup.com@MHS>
References: <20070125082203.GB7520@karelia>
	<H000006e0012cfa1.1169846620.mailx.epvgroup.com@MHS>
Message-ID: <20070127193543.GA16919@karelia>

Hi Gregorio,

I am glad things are working for you now!


Gregorio Arvilla <Gregorio.Arvilla@epvgroup.com> writes:

> I have a question about xsd. How do I create an empty instance of the
> xsd generated code and fill it with data myself (instead of the data
> coming from an xml file)?

You would start by instantiating the type that corresponds to the
root element and then use this type's modifiers that correspond
to elements and attributes to "grow" your tree. In case of the
hello example, you could do it like so:

hello_type h ("Hey"); // Construct the hello object with
                      // the greeting string.

h.name ().push_back ("Boris");   // Add a few names
h.name ().push_back ("Gregorio");


Also see the library example for some more sample code that modifies
the in-memory representation.


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/20070127/afcfe947/attachment.pgp
From beddoes at intient.com  Sun Jan 28 23:51:29 2007
From: beddoes at intient.com (Bradley Beddoes)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] serialize empty element
Message-ID: <45BD7D51.7050601@intient.com>

Hi,
I was wondering if there might be any suggestions as to how to serialize 
  to an empty element.

I have attempted to enable default ctors and serialize an object and 
this seg faults for obvious reasons.

Essentially I would like to be able to create an object representing an 
element and have it written to the DOMDocument as an empty element so 
that other code can come along and replace this empty element with on 
the fly generated content.

I am about to play around with manually inserting a node but I don't 
think this is going to be the solution I am looking for.

Bradley

-- 
Bradley Beddoes
Lead Software Architect

Intient - "Open Source, Open Standards"


From boris at codesynthesis.com  Mon Jan 29 02:44:08 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] serialize empty element
In-Reply-To: <45BD7D51.7050601@intient.com>
References: <45BD7D51.7050601@intient.com>
Message-ID: <20070129074408.GA22166@karelia>

Hi Bradley,

Bradley Beddoes <beddoes@intient.com> writes:

> I was wondering if there might be any suggestions as to how to serialize
>  to an empty element.
>
> I have attempted to enable default ctors and serialize an object and
> this seg faults for obvious reasons.
>
> Essentially I would like to be able to create an object representing an
> element and have it written to the DOMDocument as an empty element so
> that other code can come along and replace this empty element with on
> the fly generated content.

I am not quite sure what you mean here by the empty element. If the
schema allows for this element to be empty (e.g., no required
attributes and all elements are minOccurs=0, etc.) then you should
be able to serialize it without problems.

But I guess (from the segfault you've mentioned) that what you are
trying to do is serialize an element without some required attributes
or elements so that you can get the nested elements/attributes
created (though without any legal values). This is not going to work
since the generated serialization code expects the tree to be valid
and to contain all required attributes and elements. I guess you will
have to create those DOM nodes manually.

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/20070129/5ed58410/attachment.pgp
From beddoes at intient.com  Mon Jan 29 03:19:10 2007
From: beddoes at intient.com (Bradley Beddoes)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] serialize empty element
In-Reply-To: <20070129074408.GA22166@karelia>
References: <45BD7D51.7050601@intient.com> <20070129074408.GA22166@karelia>
Message-ID: <45BDADFE.6060507@intient.com>

Boris Kolpackov wrote:
> Hi Bradley,
> 
> Bradley Beddoes <beddoes@intient.com> writes:
> 
>> I was wondering if there might be any suggestions as to how to serialize
>>  to an empty element.
>>
>> I have attempted to enable default ctors and serialize an object and
>> this seg faults for obvious reasons.
>>
>> Essentially I would like to be able to create an object representing an
>> element and have it written to the DOMDocument as an empty element so
>> that other code can come along and replace this empty element with on
>> the fly generated content.
> 
> I am not quite sure what you mean here by the empty element. If the
> schema allows for this element to be empty (e.g., no required
> attributes and all elements are minOccurs=0, etc.) then you should
> be able to serialize it without problems.
> 
> But I guess (from the segfault you've mentioned) that what you are
> trying to do is serialize an element without some required attributes
> or elements so that you can get the nested elements/attributes
> created (though without any legal values). This is not going to work
> since the generated serialization code expects the tree to be valid
> and to contain all required attributes and elements. I guess you will
> have to create those DOM nodes manually.

Thats exactly right in this case to replace an empty XML DSig 
<Signature/> element with the correct calculated one, essentially the 
user would present an invalid Document structure which is the corrected, 
the empty <Signature/> being used to indicate what they wish to have 
signed (as there may be multiple places a Signature could live but you 
dont want to sign in them all).

I will play some more with the dom node stuff see what I can do. I just 
figured you may have had some hidden way to mark an element as empty and 
thus just create an element with the associated name and namespace only 
at serialization time.

Bradley

> 
> hth,
> -boris


-- 
Bradley Beddoes
Lead Software Architect

Intient - "Open Source, Open Standards"


From boris at codesynthesis.com  Mon Jan 29 03:47:55 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] serialize empty element
In-Reply-To: <45BDADFE.6060507@intient.com>
References: <45BD7D51.7050601@intient.com> <20070129074408.GA22166@karelia>
	<45BDADFE.6060507@intient.com>
Message-ID: <20070129084755.GB22166@karelia>

Hi Bradley,

Bradley Beddoes <beddoes@intient.com> writes:

> Thats exactly right in this case to replace an empty XML DSig
> <Signature/> element with the correct calculated one, essentially the
> user would present an invalid Document structure which is the corrected,
> the empty <Signature/> being used to indicate what they wish to have
> signed (as there may be multiple places a Signature could live but you
> dont want to sign in them all).

You could have done this if Signature was a simple type like string
that allowed empty content. But XML DSig has complex content with
required elements several levels down. One way you can do this is
to maybe come up with a special NULL signature that will have all
required fields set to some special (empty) values and allow you
to distinguish it as a special case. E.g., Setting the Algorithm
attribute in SignatureMethod to some special URI.


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/20070129/351463e0/attachment.pgp
From beddoes at intient.com  Mon Jan 29 04:02:03 2007
From: beddoes at intient.com (Bradley Beddoes)
Date: Sun Oct 11 15:33:52 2009
Subject: [xsd-users] serialize empty element
In-Reply-To: <20070129084755.GB22166@karelia>
References: <45BD7D51.7050601@intient.com> <20070129074408.GA22166@karelia>
	<45BDADFE.6060507@intient.com> <20070129084755.GB22166@karelia>
Message-ID: <45BDB80B.20607@intient.com>

Boris Kolpackov wrote:
> Hi Bradley,
> 
> Bradley Beddoes <beddoes@intient.com> writes:
> 
>> Thats exactly right in this case to replace an empty XML DSig
>> <Signature/> element with the correct calculated one, essentially the
>> user would present an invalid Document structure which is the corrected,
>> the empty <Signature/> being used to indicate what they wish to have
>> signed (as there may be multiple places a Signature could live but you
>> dont want to sign in them all).
> 
> You could have done this if Signature was a simple type like string
> that allowed empty content. But XML DSig has complex content with
> required elements several levels down. One way you can do this is
> to maybe come up with a special NULL signature that will have all
> required fields set to some special (empty) values and allow you
> to distinguish it as a special case. E.g., Setting the Algorithm
> attribute in SignatureMethod to some special URI.

Yes I have considered that possibility along with getting a list of ID's 
to be signed and a few others that I will test out. Will let the list 
know the best outcome in case there is any future interest.

> 
> 
> hth,
> -boris


-- 
Bradley Beddoes
Lead Software Architect

Intient - "Open Source, Open Standards"