[xsd-users] Cross file references

[Boris Kolpackov]

Hi Till,

Till Steinbach <till.steinbach at informatik.haw-hamburg.de> writes:

> To be sure to understand you right.
> 
> 1. Parse the first file into DOM.
> loop until end of file
> 	2.1 Go through the model to the next reference
> 	2.2 Do the parsing for the Reference
> 	2.3 Replace the reference with the resulting DOM
> endloop
> 3. Pass the DOM with the resolved references to the object model parser

Yes, that's exactly what I meant.


> This was my first Idea as well, but what if there are cycles in the 
> references? What if there are multiple references to the same object.
> Will the object parser use the same objects for the same elements in
> the DOM?

If you have cycles and need to share the same nodes between multiple
references (which is also will most likely be required to deal with
cycles), then this approach probably won't work.


> My schema looks like this:
> 
> <xsd:complexType name="model">
>     <xsd:complexContent>
>         <xsd:choice maxOccurs="unbounded" minOccurs="0">
>           <xsd:element name="refBar" type="sys:Device">
>           </xsd:element>
>         </xsd:choice>
>         <xsd:attribute name="refBar" type="xsd:string">
>         </xsd:attribute>
>     </xsd:complexContent>
>   </xsd:complexType>
> 
> [...]
> 
> There are lots of references. So it would require lots of work to 
> change all the types.

You don't really need to change the types. You just derive from the
generated ones and customize some aspects.

For more information on type customization see the C++/Tree Mapping 
Customization Guide:

http://wiki.codesynthesis.com/Tree/Customization_guide

As well as the examples in the examples/cxx/tree/custom/ directory.

Based on your requirements (handle cycles, shared nodes), it seems
you will have to handle this in the object model.

You can either leave the object model unchanged and resolve references
in the user code as they are retrieved. Using your schema as an example,
that would mean checking if the refBar attribute is present, if so,
looking up the expression in some map of already loaded fragments that
is kept on the side, if it is there, then returning it. Otherwise load
the object model for the referenced file, find the node in question and
then add it to the map and return that.

Alternatively, if you want to hide all this from the clients of the
object model, then you will need to customize the types that have
such references and hide all these operations in these customizations
(the map of already loaded fragments should probably go to the root
of the model). This will require some work from your side (maybe you
can use template to automate some of it). But then your requirements
are not exactly trivial either.


> Unfortunately it is not XPath!

I have only seen one example of the expression, but everything after
the file name looks like XPath to me.

Boris