W3C home > Mailing lists > Public > xmlschema-dev@w3.org > November 2005

Re: xsd substitution groups weird problem

From: Kasimier Buchcik <K.Buchcik@4commerce.de>
Date: Mon, 21 Nov 2005 11:07:55 +0100
To: sreedevi crk <sreedevi_crk@yahoo.com>
Cc: ML-xml-schema-dev <xmlschema-dev@w3.org>
Message-Id: <1132567675.1272.36.camel@librax>

Hi,

On Sat, 2005-11-19 at 21:59 -0800, sreedevi crk wrote:
> Hi
>  
> I had no luck using your codebase with xmlspy and stylus(I am using
> thier latest versions/validators).
>  
> Please let me know the tool name that you used to test your codebase.I
> would like to try using the same tool.

I used the XML Schema validation processors mentioned in:
http://lists.w3.org/Archives/Public/xmlschema-dev/2005Nov/0042.html

> Please let me know since I am new to xml/xsd, I am trying to
> understand your advice from the previous email -
> " In "Participation.xsd":
>   - Removed the declaration of the element "signatureString" and
>     imported it from an additional schema with no targetNamespace".
> I am curious to know as how it helped to solve the problem - is it the
> chameleon namespace design pattern? 

You may want to look at:
http://www.w3.org/TR/xmlschema-1/#composition-schemaImport
where the mechanism to reference schema components across namespaces
is described.

The term "chameleon" (it's not a term from the spec) is used in
conjunction with <include>s:
http://www.w3.org/TR/xmlschema-1/#compound-schema
A "chameleon include" names a scenario where an included schema has no
targetNamespace and and including schema has a targetNamespace; in
effect, the included components, normally in no targetNamespace,
are converted to have the targetNamespace of the including schema.
I.e. chameleon like, the included components change the color of
what would have been their targetNamespace according to the including
schema.

What helped to solve the problem was a plain import of components
with no targetNamespace; omitting the "namespace" attribute
in an <import> statement and importing a schema with no targetNamespace.
Think of it as the same as importing a schema with a different
targetNamespace.

> Also I think you are right that there could be bug in xmlspy/stylus
> while generating the original instance document -

I think this might be the point where my and your experience with
the presented scenario diverge: I just validated the instance document
with the bunch of schemas. You seem to auto-generate an instance
document based on the schemas. So maybe this auto-generation
might work incorrect.
I cannot help you here, since I've no experience with auto-generation
of instances based on XML Schemata.

> After rereading "Schema definitive guide" book regarding substitution
> groups and its two alternatives(choice groups, type substitution) - In
> my example xsds, though, I used SUBSTITUTION GROUPS(more than one
> level deep),  the generated instance document treates it as TYPE
> SUBSTITUION  since it has entry for xsi:type and expects user to fill
> in the type. This happens only in case IMPORT statement usages instead
> of  INCLUDE statement usuage. 
>  
> Your help and time in this regard is highly appreciated.

You might first check what produces the error exactly. Is it the
imported schema with no targetNamespace? Or is it the substitution
mechanism?
Try both issues with reduced scenarios, testing 1 issue at a time.

When searching for a XML Schema tool to auto-create instances:
- http://www.w3.org/XML/Schema
- asking at xml-dev@lists.xml.org may also be of help
- google (but I guess you've already tried)

Regards,

Kasimier
Received on Monday, 21 November 2005 10:08:05 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 11 January 2011 00:14:51 GMT