> 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.
I normally use eclipse, but a more light weight one would be better.

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

> >>   2. Use a more powerful schema definition language.
>
Ok, that sounds interesting - but there is not so much time to
investigate these languages in detail.

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

	<xs:complexType name="ItemType" >
		<xs:sequence>
			<xs:element maxOccurs="1" type="ItemOperFlags" minOccurs="0"
name="ItemFlags" />
		</xs:sequence>
		<xs:attribute use="optional" type="xs:dateTime" name="validFrom" />
		<xs:attribute use="optional" type="xs:dateTime" name="validUntil" />
	</xs:complexType>

	<xs:complexType name="NormalItemType">
		<xs:complexContent>
			<xs:extension base="ItemType">
				<xs:sequence>
					<xs:element type="xs:string" name="ItemContent" />
				</xs:sequence>
				<xs:attribute name="name" type="xs:string" use="required"></
xs:attribute>
			</xs:extension>
		</xs:complexContent>
	</xs:complexType>

I know, that the type xs:string for ItemContent is not the best, but
that is given by the database structure.

> Prepare for the world of fun. If you're worrying about your
> users being unable to comprehend that you always want Name
> element before Content element... you should be worrying
> about well-formedness constraints inherent in any kind of
> XML processing first. How do you expect them to understand
> that XML is case-sensitive, that 'tags' must be properly
> closed and nested, that certain characters are off-limits
> and others should always be escaped as entities or
> character references?
>
The xml restrictions to the files should be handled by using an xml
editor. But as the most xml editors are not very good in handling xml
schema validation, this should be quite simple.

Sven