-
Notifications
You must be signed in to change notification settings - Fork 2
How to write a MergeSchema
This chapter provides you with the necesary knowledge about how to write a mergeschema for a namespace.
-
The page The merge schema
-
Knowledge of the XML namespace you want to write the merge schema for.
-
The document definition (a XML Schema Definition or a Document Type Definition)
This chapter provides a set of questions that will lead you through the creation of a MergeSchema.
-
What is the uri of the namespace this merge schema will cover? Use the uri for the
namespace
attribute -
Is the
schemaLocation
of the documents to be merged pointing at a remote file? Use the location of a local schema for thelocation
attribute. If theschemaLocation
points to a local file thelocation
attribute can be left blank. -
Can there be another namespace uri for the document definition? If yes add an
<additional-namespace>
to the<definition>
element.
<definition namespace="http://someNamespace.uri" location="path/to/local/schema">
<additional-namespace namespace="http://someNamespace-v-1-2.uri"/>
</definition>
The default-criterion
element is optional. It will be used in all handling
elements with no cirterion
specified. Its default is
<default-criterion xpath="./" ordered="false"/>
-
What xpath expression can be used to identify the most elements in the namespace? Consider using that expression for the xpath attribute. i.e. if most of the elements can be identified via an id attribute consider setting xpath="./@id".
-
Will the evaluation of the xpath expression return a set and will the ordering of the set be relevant? Set ordered="true"
-
Defines the schema definition a single possible root for all documents of this namespace (i.e. will all documents of that namespace have the same root tag) ? If no set root="false" in the merge schema’s root.
For all elements in the namespace an handling
element is created as follows:
-
Use the local name of the element for the for attribute.
-
Does this
handling
overwrite an already existinghandling
element? If yes set thishandling
as a child of thehandling
that covers the elements parent. If no set thishandling
as a sibling to the last one created.
-
-
Should this element occur only once per sibling axis? If yes set unique="true"
-
Can you attach values to the textual content of the element? If yes then set attach-text="true" in the
handling
element. -
Does the element extend another element? Set scope-ref="someLabel" and namespace-ref="someNamespaceUri" with "someNamespaceUri" pointing to the parent namespace and "someLabel" pointing to the
handling
element in "someNamespaceUri"'s merge schema. That so referedhandling
element needs it’s label attribute set to "someLabel" to be found. -
Will this handling ever be referenced by another
handling
? Then you should give it a document wide unique label with label="someUnique". -
Can’t the element be identified using the default criterion? If yes
-
Set a
criterion
element with xpath="./some/x/@path" whith "./some/x/@path" refering to the elements matching relevant properties.-
If the outcome of the xpath evaluation is a list of nodes and their order is important for a match then set ordered="true".
-
If the element is declared as unique consider setting xpath="true()" to match those elements in any case.
-
-
-
For all attributes of the element
-
Can you attach values to the attribute value? If yes set an attribute with name as the name of the attribute and attachable="true".
-
Is a string needed to separate the attached values? Use that string for the separationString attribute
-
-
<merge-schema for="rootElement">
<definition .../>
<default-criterion xpath="./default/@xpath"/>
<handling for="anElement">
<handling for="anotherElement" unique="true">
<criterion xpath="./another/x/@path"/>
</>
<attribute name="someList" attachable="true" separationString=","/>
</>
</>