> It's illuminating in that it clearly states one
> person's view of the
> process. 

Illuminating was the thread, because 
at the time I read it, some months later, 
I found many answers for my problems,
because I saw that I was not alone 
in getting crazy to understand the schema and
because I laughed for:

>I seem to be inventing the rules as I go along...
Help!

;-)

>However, the notion that you can implement
> xs:include by creating
> schema components from the referenced schema
> document and then including the
> (perhaps modified) components is simplistic, because
> you don't have enough
> information to construct the components until you
> have assembled all the
> components that they refer to

I agree, for me, first you solve names 
and references in the definitions using the 
composition-tns-labeled tree, 
and then you go on, do you think is correct ?

For resolving I intend to agument the name-definition
and the referenced-name-definition with:
    - schema component name 
    - schema component target-namespace 

In my experience it works.

> - for example, you
> don't know the {variety} of
> a simple type until you have found its base type. So
> these components are at
> best "skeletal components", a concept which isn't
> exactly clear from the
> spec...

If I well understand the agumented definitions I
propose fall in the humblest
category of 'skeletal components': 
definitions + names and refs resolved,
many other 'transformations' are needed 
to get to the final result...

Cheers
Michele Vivoda





	
		
___________________________________ 
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: 
http://it.docs.yahoo.com/nowyoucan.html