Please don't remove the attributions, and leave enough
quoted material to provide context for your words. Google
Groups inserts attributions by default unless I'm much
mistaken. Most of use are reading ctx using newsreaders,
and it's far more convenient to have all the context in one
place, instead of shuffling through the whole thread to see
who said what and what you're referring to in your
follow-ups.

Sven <sven@a...> wrote in
<1194261018.460098.315420@o...>:
>> If your editors are techies, it's perfectly possible to
>> explain to them that there are certain rules they should
>> observe. If they are not, they have no business editing
>> raw XML documents, and you should provide them with an
>> application-specific editor instead.
>
> Unfortunately they are no techies, just database
> administrators. But they a common with handling complex
> data files like csv.
> 
> The idea for a database specific editor already came to me
> too. But first I want to provide just a xml editor which
> can validate against a schema. Perhaps someone can give me
> a hint for a good one, especially platform independent.

Can't help you on this one, try asking for the input from
group regulars. Note that you'll have to do with a
restrictive schema in this case.

>> 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).

>> >>   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.

-- 
"I can't help but wonder if you... don't know a hell of a
lot more about practically every subject than Solomon ever
did."