RE: XSDL best practices question/suggestions

Roger,

The list is accessible from the Schema WG page.

> -----Original Message-----
> From: Roger L. Costello [mailto:costello@mitre.org]
> Sent: Friday, February 09, 2001 12:01 PM
> To: Fuchs, Matthew
> Cc: 'www-xml-schema-comments@w3.org'; costello@mitre.org
> Subject: Re: XSDL best practices question/suggestions
> 
> 
> Hi Matthew,
> 
> [Sorry for the delay.  Been on travel. I don't seem to be 
> subscribed to
> this list group, so I don't know if there were any responses to your
> post. (How do I subscribe?)]
> 
> Here are my comments:
> 
> > > Therefore I recommend you structure your schema(s) as a tree,
> > > with a root file containing only includes and no definitions,
> > > and the other files containing imports and definitions, but no
> > > includes. This way, your only file system dependency is in the 
> > > root file ...
> 
> Hmm, I don't quite see this. Both the <include> element as well as the
> <import> element reference a (schema) file.  For example:
> 
> <include schemaLocation="URI to a schema file"/>
> 
> <import namespace="namespace of schema"
>         schemaLocation="URI to a schema file"/>
> 
> With both elements a file is referenced.  Thus, if you change the name
> of a schema file it will impact all schemas that reference it,
> regardless of whether it is being referenced using <include> or
> <import>.  Thus, I don't see how using <include> minimizes file
> dependencies any more than <import> does.  Perhaps I am not
> understanding your point?  /Roger
> 

The schemaLocation attribute in the <import> is only a hint - and is not a
required attribute.  Import does not at all imply that a file is referenced
- you may get your definitions from a database.  The schemaLocation
attribute on the <include> is required and if it resolves, must resolve to a
chunk of text ("a resource of type text/xml", to quote the spec), or those
definitions are not available for validation.  Likewise, a <redefine>
references a chunk of text.  So one additional item is that one should not
use the schemaLocation attribute of <import> in a multi-file schema, as one
then has the unfortunate circumstance that people might be refering to
different copies/versions of that schema through schemaLocation and fixing
all those references if files change will be _bad_ - if I move the imported
schema, I must hunt down and change every schemaLocation reference to it.

But to get back to the point at hand.  Suppose I have a schema, foo, which
I've arbitrarily divided into files, A, B, and C.  Both A and B include C
for some particular definition, but can otherwise be considered free
standing.  Now suppose somebody decides C is getting too big to work with,
so they're going to move that definition from C to B.  B works, C works, but
A doesn't.  Oops.  Alternatively, suppose I choose to split C into two
files.  I need to check that all the includes for everyone works.  This can
get rather hairy - and then no one knows what to include anymore.  Or
suppose I need to move my files around, or send them to someone else.  They
(or I) may need to go through all the includes to make sure they still work.

Now suppose you have a file, foo, which includes A, B, and C.  Then it
doesn't matter if you move component among the three files - everything is
visible to everything else because they are included by foo.  If you want to
split C in two parts, then you just add another include to foo.  And if you
move everything around, you just go to foo and correct it.

So all you file system dependencies are in one file.  (If you really want to
use schemaLocation with <import>, you can put a version of import without
the attribute in the A, B, and C files, and a version with schemaLocation in
the foo file.  This may seem a little redundant, but you still maintain all
your file system dependencies in one file, rather than smeared out all over
your schema.)

Matthew

Received on Friday, 9 February 2001 20:10:57 UTC