[xsd-users] RE: serializing ##other

[mhoffm1060 at aol.com]

Hi Boris,
I was wondering if this feature was still being perused.  ( I would like to be able to get the DOMElement(s) for the xml that falls into the ##other category ).
 
If this is still in development is there any idea of when it will make it into a release?
 
Thanks,
Mark
 
 
[xsd-users] serializing ##other
Boris Kolpackov boris at codesynthesis.com 
Thu Jan 11 16:06:01 EST 2007 
Previous message: [xsd-users] serializing ##other 
Next message: [xsd-users] [Problem] Types not found. 
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] 
Hi Bradley,

Bradley Beddoes <beddoes at 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
________________________________________________________________________
AOL now offers free email to everyone.  Find out more about what's free from AOL at AOL.com.