[xsd-users] Re: building statical-typed tree -> no internal DOMNodes

[Boris Kolpackov]

Hi Oliver,

[I've CC'ed xsd-users back in.]

Oliver.Kowalke at infineon.com <Oliver.Kowalke at infineon.com> writes:

> if I have a statical-typed tree (calsses) generated by xsd-tool - I can
> construct a xml representation from this classes.
> Like:
>
> abc::a_type a_n;
> abc::b_type b_n;
> a_n.b( b_n);
>
> But the associated DOMNodes are NULL-pointer?!

That's right. You only get DOM association if the tree is created during
parsing and keep_dom flag is on. There are two ways you can add DOM
association to a constructed tree:

1. Manually create a DOM document and associate it with with the tree
   using _node (DOMNode*) function. This is a major burden for anything
   but trivial documents.

2. Serialize your tree into a DOMDocument and then re-parse it with
   the keep_dom flag.


> So adding xsd:any nodes are not possible?

I told you that working with type-less content in a typed tree is going
to be a major pain ;-). Let me suggest a different approach to your
problem. If I understood you correctly, you know what type of content
might be provided for xsd:any. In your example, it is either text or
a sub-document with predefined structure (embed.xsd). The idea of the
approach is to "extend" the schema (hello.xsd) in such a way, that the
generated code will have "slots" to hold all possible type-less content.
We only use such extended schema for code generation and still use the
original schema for validation so we do not actually allow non-conforming
documents that resulted from such an extension. So here is how we would
extend your hello.xsd to support text content and embed.xsd:

<?xml version="1.0"?>
<xsd:schema targetNamespace="abc"
            xmlns="abc"
            xmlns:xyz="xyz"
            xmlns:xsd="http://www.w3.org/2001/XMLSchema"
            elementFormDefault="qualified">

  <xsd:import namespace="xyz" schemaLocation="embed.xsd"/>

  ...

  <xsd:complexType name="c_type" mixed="true">
    <xsd:sequence>
      <xsd:any namespace="##other" processContents="skip" minOccurs="0"/>
      <xsd:element name="embed_content" type="xyz:embed_type" minOccurs="0"/>
      <xsd:element name="text_content" type="xsd:string" minOccurs="0"/>
    </xsd:sequence>
  </xsd:complexType>

  ...

</xsd:schema>

Note that when the instance (hello.xml) is parsed by code generated from
this schema, the embed or text still matches the xsd:any and only accessible
via DOM. Now the plan works like this:

1. You wrap the parsing function. In your wrapper you will determine
   what type of content is in xsd:any (text or embed), extract it, and
   either set text_content if it was text or parse embedded xml and set
   embed_content.

2. You wrap serialization function. In your wrapper you remove information
   from either embed_content or text_content, serialize the tree to
   DOMDocument, patch-up the document with the info from embed_content or
   text_content to correspond to xsd:any, and serialize the resulting DOM
   document to XML. I already covered this step in one of my previous posts.

3. Clients of your library:

   a. Call your parser wrapper to parse XML into a tree.

   b. The xsd:any info is accessible to them either via embed_content
      or text_content. They read and modify the information only via
      these accessors.

   c. Call your serialization wrapper to write tree into XML.

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/20060412/a1e8ad9c/attachment.pgp