[xsd-users] ##any type problems

[Boris Kolpackov]

Hi Bradley,

I've CC'ed xsd-users to my reply; some of the information below
could be useful to others.

Bradley Beddoes <beddoes at intient.com> writes:

> Linux 64bit Fedora and 32bit Fedora is the development environment which
>  would be good for now, further down the track we will need a larger
> range of OS's perhaps (Windows/OSX).

The fix will be part of the upcoming (beginning of Jan) 2.3.1 and thus
supported on all platforms. What is the platform you are using for
code generation right now?


> >I looked into PSVI today but could not find a way to determine if an
> >element was matched by a wildcard. I am still going to ask on the
> >Xerces-C++ mailing list.
>
> I will be interested to know the outcome of this for my own work with
> xerces actually.

I sent an email to the Xerces-C++ mailing list but there is no reply
yet. I am, however, pretty sure there is no way to obtain the
necessary information based on my studying of how things work. I am
going to change the error to a warning for now.


> >BTW, out of curiosity I checked how this is supported in other data
> >binding tools. I particularly looking into XMLBeans and, guess what,
> >it silently generates broken code.
>
> Broken how?

Here is a simple test schema:

<?xml version="1.0" encoding="utf-8"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema" xmlns:t="test" targetNamespace="test">

  <complexType name="Type">
    <sequence>
      <element name="foo" type="string" minOccurs="0"/>
      <element name="bar" type="string"/>
      <any namespace="##any"/>
    </sequence>
  </complexType>

</schema>

XMLBeans generates a number of functions for each element, one of which is
isSetFoo. Here is its implementation:

public boolean isSetFoo()
    {
        synchronized (monitor())
        {
            check_orphaned();
            return get_store().count_elements(FOO$0) != 0;
        }
    }

Where FOO$0 is a QName for the "foo" element. Now imagine an instance
which omits the first "foo" element but has "foo" in place of the
wildcard.



> The JAXB bindings generator actually creates a member variable of type
> org.w3c.dom.Element which you can see in the attached source code.

I think you forgot to attach the code. Hopefully the example with
XMLBeans will help you check whether JAXB can handle this properly.
If it does, then it would be interesting to know how.


> This
> obviously means that you need to create a second JAXB unmarshaller
> instance to deal with the types of element you reasonably expect to
> receive as the any element in your instance documents. We have had the
> same situation elsewhere with JAXB handling the any type however and it
> does not pose to much of an issue.

You can do the same in XSD with the DOM association feature. If you pass
the keep_dom flag to one of the parsing function, then you can obtain
the corresponding DOM node for any C++/Tree node and use that to parse
things further.


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/20061220/d2af10d2/attachment.pgp