> >> If your editors are not techies, and you let them edit
> >> raw XML documents, and try to design a 'loose' schema for
> >> their convenience, they'll break your system six ways
> >> till Thursday. Of course, it's your blood pressure, so
> >> feel free to jump off that particular cliff.
>
> > I'll keep that simple. If the xml file cannot be parsed by
> > my application it will be refused.
>
> I know I sound like a broken gramophone, but - stick to a
> restrictive schema if you can. There are simply to many
> problems with loose schemata: needless complications in
> your parser/application code, needless complications in
> schema itself and escalation (users wanting more and more
> freedom, eventually getting to the point where you start
> considering implementing ExtraSensoryParser).
>
Yes, I agree with you to define a strict schema that matches the data
structure in memory.
But anyway I cannot see a good reason why there has to be a fixed
order of the elements in a sequence at all. When I have a class with
attributes or a database entry I don't care about their ordering also.
Even the attributes of a xml element are not ordered.

> >> >>   4. Design a well-structured document:
>
> >> >>       <temperature scale="celsius">27</temperature>
> >> >>       <sky>cloudy</sky>
>
> >> > The sample provided above is not the original document.
> >> > It just a simplified example to describe the problem.
> >> > I think I described a quite well-structured schema
> >> > already
> >> > :-)
>
> >> You didn't, and my example demonstrates why.
>
> > Ok ok - I think I explained it wrong. The example has
> > nothing to do with my data. I just wanted to have a short
> > description about what I mean. Here is a short part of my
> > schema - I did not want to post it, because I use self
> > defined complex types in it:
>
> [snip type definition]
>
> Correct me if I'm wrong, but you want to derive numerous
> sub-types from ItemType, with different content models
> depending solely on content of ItemFlags child element? If
> so, the same warning still applies. You can only do that by
> defining a generic element of ItemType in your schema and
> specifying a sub-type using xsi:type attribute on those
> elements in your document.
>
Perhaps my english is too bad, but I do not really understand what you
want to say.
Especially what you mean with "different content models
depending solely on content of ItemFlags child element".
ItemFlags is common in all derived types, so I define it in the base
type ItemType to reduce redundance.

Thanks, Sven