[xsd] Guidelines [was: [xsd] Schema in multiple documents]

[Chizzolini Stefano <chist@csb.it>]

Thanks, Masaaki.

Yeah, I read Kohsuke Kawaguchi's famous article on xml.com
(http://www.xml.com/pub/a/2001/06/06/schemasimple.html) about one year ago,
but I do not agree with several considerations of his own: my opinion
adheres to the counterpoint proposed by Dare Obasanjo
(http://www.xml.com/pub/a/2002/11/20/schemas.html) on xml.com and then on
MSDN
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnxml/html
/xmlschemacomplex.asp).

Each mind sits upon its favourite niche and fits its environment so much as
possible! I say: as Mr Kawaguchi is the guru of RELAX NG while Mr Obasanjo
is a first-class employee at Microsoft (which massively supported the W3C
XML Schema WG), what do you imagine would be their respective opinions? ;)

Regards,
Stefano

> -----Messaggio originale-----
> Da:	Masaaki KOGA [SMTP:koga@a-dos.com]
> Inviato:	venerdì 17 dicembre 2004 3.33
> A:	Chizzolini Stefano
> Cc:	xml-dev@lists.xml.org
> Oggetto:	Re: [xml-dev] [xsd] Schema in multiple documents
> 
> Hello Chizzolini,
> 
> I'm trying to use XML Schema(XSD) too.
> 
> There are many ways to define a schema with XSD.
> the following URL is the article about 'how to avoid the pitfalls'.
> 
> http://www.kohsuke.org/xmlschema/XMLSchemaDOsAndDONTs.html
> 
> That maybe help you.
> 
> And also, there are many practical XSDs.
> As I know, it seems the best practice is as following sample.
> 
> http://www.rosettanet.org/PIP7C7
> (download zip file, then extract
>  and find root xsd file in 'XML/Interchange' directory)
> 
> That is the standarized xml based message schema about 
> notifing of Semiconductor Test Data. That design is 'Modular based'.
> I think that is a good sample for designing XSD.
> 
> Regards,
> 
> Masaaki KOGA
> 
> 
> On Wed, 15 Dec 2004 12:50:06 +0100
> Chizzolini Stefano <chist@csb.it> wrote:
> 
> > Hi all
> > 
> > I'm defining a schema (via XML Schema) stretched over multiple
> documents,
> > but I feel quite unsure about the best strategy to reference its
> definitions
> > each other across the file boundaries.
> > What I need is a clean method to enable the reuse of components.
> > 
> > As I know, there are mainly two constructs from the XSD namespace for
> this
> > purpose:
> > - include element: same target namespace as the including document;
> > - import element: any target namespace.
> > (I chose the include element as it seems to fit my case).
> > 
> > My headache comes when I try to establish WHICH document references WHAT
> > ELSE.
> > 
> > For example (the target namespace is the same for all the documents):
> > - document A contains common types (it could be considered the main
> document
> > for the target namespace);
> > - document B contains derived types;
> > - document C contains other basic (non-derived) types;
> > - documents FF are future extensions of the target namespace.
> > Document A should be reused by B and FF.
> > 
> > Should I:
> > - include A inside B and FF, whilst C inside A? This way all the common
> > components are centrally referenced by A, while any extension document
> (B or
> > FF) has just to care about referencing the main document (A). This
> should
> > improve the referential consistency and smooth expandability, but forces
> any
> > instance document to reference the location of a specific "leaf" schema
> > document (I say, B or FF) as the main document (A) isn't aware about any
> > extension document (it has just references to basic component documents
> like
> > C)!
> > - include A inside B and FF, whilst B and FF and C inside A? This way
> any
> > instance document could reference just the main document (A) and use all
> the
> > derived types at a time, but the references across the schema documents
> > would be multiplied and would cause circular references (is it legal?
> may it
> > affect the validator performance?). As another side effect, the main
> > document should be updated any time an extension document is created.
> > 
> > Which solution do you think that's better?
> > Is there another (better) approach?
> > 
> > Thanks for the tips!
> > 
> > Stefano