> 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
