XML Editor
Sign up for a WebBoard account Sign Up Keyword Search Search More Options... Options
Chat Rooms Chat Help Help News News Log in to WebBoard Log in Not Logged in
Show tree view Topic
Go to previous topicPrev TopicGo to next topicNext Topic
Postnext
David JaramilloSubject: XQuery to consolidate modular XML Schemas - any help?
Author: David Jaramillo
Date: 08 Dec 2004 11:32 AM
Originally Posted: 08 Dec 2004 11:22 AM
I have following problem:<br> I have an XML Data model composed of one main XML Schema importing constructs<br> from other XML Schemas.<br> I need to create a single consolidated schema document file, containing the everything of the <br> main XML schema plus all referenced elements, attributes and type definitions of the imported<br> XML schemas (note: only referenced constructs, not everything).<br> <br> I think this could be done by using Xquery, and maybe anybody has already made experiences<br> with this kind of task. <br> If not, does anybody has ideas how to acomplish it?<br> <br> The reason why I need this is: we are creating C++ classes out of the main XML-Schema. The tool we<br> use makes classes for everything contained in the imported schemas. Our schemas are very huge <br> and complex, so we get a lot of code for constructs that we never need in our application.<br> <br> Another aspect arises when it comes to sharing the model with external parters, we don't want to <br> expose the full schemas, but only those portions which are relevant for the correponding model.<br> <br> Any help would be highly appreciated.<br> Thanks,<br> David

Postnext
(Deleted User) Subject: XQuery to consolidate modular XML Schemas - any help?
Author: (Deleted User)
Date: 09 Dec 2004 05:42 AM
Hi David,
here is a query that you can use as a starting point. It will import the
definitions that are in an included file (not definitions coming from an
imported file, as those would be in a different namespace and a single
xsd:schema has just one targetNamespace). One of the limitations this
query has is that it will look just one level deep (e.g. it will not
import definitions coming from a schema included by an included schema).

Hope this helps,
Alberto


declare namespace xsd = "http://www.w3.org/2001/XMLSchema";

declare variable $schema := doc("ipo.xsd")/xsd:schema;
declare variable $includeSet := $schema/xsd:include;
declare variable $toProcess := $schema/(* except xsd:include);

declare function local:search(
$typeToSearch as xs:string,
$node as element(),
$qNameToSearch as xs:string) as element()?
{
let $prefix:=substring-before($qNameToSearch,":"),
$name:=substring-after($qNameToSearch,":")
for $include in $includeSet
return
if(namespace-uri-for-prefix($prefix,$node) eq $schema/@targetNamespace)
then
if(exists($include/@schemaLocation))
then (
let $includedSchema:=doc($include/@schemaLocation)/xsd:schema
return $includedSchema/xsd:*[local-name()=$typeToSearch][@name=$name]
)
else ()
else ()
};

declare function local:navigateElement($node as element(xsd:element)) as element()?
{
if(exists($node/@type))
then
let $a := local:search("complexType", $node, $node/@type)
return if(empty($a))
then local:search("simpleType", $node, $node/@type)
else $a
else
if(exists($node/@ref))
then local:search("element", $node, $node/@ref)
else local:includeReferencedDefs($node/*)
};

declare function local:navigateAttribute($node as element()) as element()?
{
if(exists($node/@type))
then local:search("simpleType", $node, $node/@type)
else
if(exists($node/@ref))
then local:search("attribute", $node, $node/@ref)
else local:includeReferencedDefs($node/*)
};

declare function local:navigateGroup($node as element()) as element()?
{
if(exists($node/@ref))
then local:search("group", $node, $node/@ref)
else local:includeReferencedDefs($node/*)
};

declare function local:navigateAttributeGroup($node as element()) as element()?
{
if(exists($node/@ref))
then local:search("attributeGroup", $node, $node/@ref)
else local:includeReferencedDefs($node/*)
};

declare function local:navigateSimpleType($node as element()) as element()?
{
if(exists($node/@base))
then local:search("simpleType", $node, $node/@base)
else local:includeReferencedDefs($node/*)
};

declare function local:navigateComplexType($node as element()) as element()?
{
if(exists($node/@base))
then
let $a := local:search("complexType", $node, $node/@base)
return if(empty($a))
then local:search("simpleType", $node, $node/@base)
else $a
else local:includeReferencedDefs($node/*)
};

declare function local:includeReferencedDefs($nodes as element()*) as element()*
{
for $node in $nodes
return
typeswitch($node)
case element(xsd:element) return local:navigateElement($node)
case element(xsd:attribute) return local:navigateAttribute($node)
case element(xsd:group) return local:navigateGroup($node)
case element(xsd:attributeGroup) return local:navigateAttributeGroup($node)
case element(xsd:simpleType) return local:navigateSimpleType($node)
case element(xsd:complexType) return local:navigateComplexType($node)
default return local:includeReferencedDefs($node/*)
};

<xsd:schema>
{
$schema/@*,
$toProcess,
local:includeReferencedDefs($toProcess/*) except $toProcess
}
</xsd:schema>

Postnext
David JaramilloSubject: XQuery to consolidate modular XML Schemas - any help?
Author: David Jaramillo
Date: 10 Dec 2004 04:34 AM
Hello Alberto!
Thanks for the reply and the query. I'm quite new to XQuery. The query you provided
is a good starting point, but restricted to "includes". As you noticed, the big issue
to solve is the "imports" since "includes" use by default whole contents of
the included XML Schema document.

The question I now have is: Do you think
is it possible to solve this task by using XQuery? If an expert like you gives
me a "hope" that it can be done, then I will try. But, if from the beginning it's
hopeless, say due to the nature of XML-Schema definition, then I won't waste my
time and will have to resignate :-(

Thanks & Regards.

David

Postnext
(Deleted User) Subject: XQuery to consolidate modular XML Schemas - any help?
Author: (Deleted User)
Date: 10 Dec 2004 05:14 AM
Hi David,
from the point of view of the query, "import" is not much different from "include".
The problem is that the resulting XMLSchema is invalid, or, at least, modeling
a different XML file.

As an example, let's take these two schemas:

first.xsd:

<xs:schema targetNamespace="http://www.example.com/first"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:r="http://www.example.com/first"
xmlns:s="http://www.example.com/second"
elementFormDefault="qualified">

<xs:import namespace="http://www.example.com/second" schemaLocation="second.xsd"/>

<xs:element name="root">
<xs:complexType>
<xs:sequence>
<xs:element ref="s:part" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>

second.xsd:

<xs:schema targetNamespace="http://www.example.com/second"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:s="http://www.example.com/second">

<xs:element name="part">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:pattern value="\d{3}-[A-Z]{2}"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
</xs:schema>

first.xsd defines elements and attributes inside the http://www.example.com/first
namespace, while second.xsd defines them inside http://www.example.com/second.
A sample XML that is valid looks like this

<f:root xmlns:f="http://www.example.com/first" xmlns:s="http://www.example.com/second" >
<s:part>999-AV</s:part>
</f:root>

If you merge the two definitions in one schema, like this

global:xsd:

<xs:schema targetNamespace="http://www.example.com/first"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:r="http://www.example.com/first"
elementFormDefault="qualified">

<xs:element name="root">
<xs:complexType>
<xs:sequence>
<xs:element ref="r:part" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>

<xs:element name="part">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:pattern value="\d{3}-[A-Z]{2}"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
</xs:schema>

you end up having both "root" and "part" inside the same namespace;
a sample XML that is valid according to this merged schema is this

<root xmlns="http://www.example.com/first">
<part>999-AV</part>
</root>

Alberto

Postnext
David JaramilloSubject: XQuery to consolidate modular XML Schemas - any help?
Author: David Jaramillo
Date: 10 Dec 2004 10:57 AM
The solution I was looking for should provide an "equivalent" global
XML Schema document, e.g. the XML docuemnts should be still valid against it.

So the conclusion is, that it is not possible to create
a consolidated XML Schema document, because import constructs are used to
combine together XML Schema components from different namespaces, but
the resulting "global" XML Schema Document (per definition) can only have
one target namespace.

Is this conclusion correct?

Thanks again,
David

Posttop
(Deleted User) Subject: Re: XQuery to consolidate modular XML Schemas - any help?
Author: (Deleted User)
Date: 10 Dec 2004 11:07 AM
Hi David,

At 11.00 10/12/2004 -0500, stylus-studio-xquery Listmanager wrote:
>From: David Jaramillo
>
>The solution I was looking for should provide an "equivalent" global
>XML Schema document, e.g. the XML docuemnts should be still valid against it.
>
>So the conclusion is, that it is not possible to create
>a consolidated XML Schema document, because import constructs are used to
>combine together XML Schema components from different namespaces, but
>the resulting "global" XML Schema Document (per definition) can only have
>one target namespace.
>
>Is this conclusion correct?

Yes; you must have different XMLSchema documents for each namespace that
your XML file uses.

Alberto


 
Go to previous topicPrev TopicGo to next topicNext Topic
Download A Free Trial of Stylus Studio 6 XML Professional Edition Today! Powered by Stylus Studio, the world's leading XML IDE for XML, XSLT, XQuery, XML Schema, DTD, XPath, WSDL, XHTML, SQL/XML, and XML Mapping!  
go

Log In Options

Site Map | Privacy Policy | Terms of Use | Trademarks
Stylus Scoop XML Newsletter:
W3C Member
Stylus Studio® and DataDirect XQuery ™are from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2016 All Rights Reserved.