[xsd-users] Cross file references

Till Steinbach till.steinbach at informatik.haw-hamburg.de
Fri Aug 5 03:45:09 EDT 2011


Hi Boris,
thanks a lot for your advices!


> The "<referencing element" part above is not legal XML.

Oh you are right! I missed a underscore:
<referencing_element refBar="foo.xml#//foo/bar[@name='foobar']">
was ment


> There are generally two approaches to handling this which can be
> called "before schema" and "after schema".
> 
> With the "before schema" approach your XML Schema (and the resulting
> C++ object model) doesn't know anything about references and expects
> XML as a single, complete file (or stream). The way to handle this
> with XSD is to first parse the XML file into DOM and then pre-process
> it (by resolving all the references) before handing it off to the
> object model parser.
> 
> The major drawback of this approach is that you cannot use XML Schema
> validation since that happens during the XML-to-DOM parsing stage and
> since your schema doesn't know anything about references, validation
> will fail.

The missing Schema validation is no problem.

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

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?

Example:
<models>
	<model id="1">
		<referencing_element refBar="foo.xml#//foo/bar[@name='foobar']">
	</model>
	<model id="2">
		<referencing_element refBar="foo.xml#//foo/bar[@name='foobar']">
	</model>
</models>

This should be resolved as two model objects with pointers to the same bar object!


> The "after schema" approach assumes that your schemas are aware of the
> referencing mechanism. For example, the schema can look like this:
> 
>  <complexType name="bar">
>    <sequence minOccurs="0">
>      <element name="data" type="string"/>
>    </sequence>
>    <attribute name="refBar" type="string"/>
>    <attribute name="name" type="string"/>
>  </complexType>
> 
>  <complexType name="model">
>    <sequence>
>      <element name="bar" type="bar"/>
>    </sequence>
>  </complexType>
> 
>  <element name="model" type="model"/>
> 
> Which allows the instance to look like this:
> 
>  <model>
>    <bar name="foobar">
>      <data>ddd</data>
>    </bar>
>  </model>
> 
> Or like this:
> 
>  <model>
>    <bar refBar="..."/>
>  </model>

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>

So it would allow either bar to be an element of model or a reference as string attribute.

> With this approach you can have XML Schema validation enabled. You can
> also resolve the references in the DOM document before handing it off
> to the object model or you can do it in the object model (since the
> object model will contain the references). You can even customize the
> generated object model (the model type in the above example) to load
> the referenced elements automatically or even lazily.
> 
> Which approach to choose for reference resolution will probably be
> influenced by the number of types that can have such references. If
> the number of great then it may be too tedious to customize every
> type and the generic DOM approach may be an easier solution.

There are lots of references. So it would require lots of work to change all the types

> Also your references look a lot like XPath so you can probably use
> the XPath processor (either the one that comes with Xerces-C++ or
> XQilla) to resolve them.

Unfortunately it is not XPath! It's an EMF special syntax, but it would be no problem to preprocess it and make it XPath style. The problem is that XPath does not allow referencing other files I think. That is in my eyes the biggest issue that forces me to resolve the references manually.


Thanks for your help!
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2476 bytes
Desc: not available
Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20110805/1094567b/smime.bin


More information about the xsd-users mailing list