Sven <sven@a...> wrote in
<1194269239.326977.316460@d...>:
>> > 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.

But your *tools* probably do - where internal representation
is concerned.

pavel@debian:~/dev/c/st$ a st.c
#include <stdio.h>
struct A { int a ; float b ; } t = {1729 , 1729.0} ;
typedef struct B { float b ; int a ; } B ;
int main () { printf ("%d\n" , (* (B *) &t).a) ; }
pavel@debian:~/dev/c/st$
gcc -ansi -Wall -Wextra -pedantic -O2 st.c
st.c: In function ‘main’:
st.c:4: warning: dereferencing type-punned pointer will
break strict-aliasing rules
st.c:4: warning: control reaches end of non-void function
pavel@debian:~/dev/c/st$ ./a.out
1155014656
pavel@debian:~/dev/c/st$

> Even the attributes of a xml element are not ordered.

Well, let me overexaggerate a bit for dramatic effect.
Imagine a 92GB XML document containing information about a
few hundred thousand entities, each having some fifteen
thousand properties:

  <data>
    <entity>
      <prop1>1.356</prop1>
      <prop2>Wonka wonka.</prop2>
      <prop3>red</prop3>
      <!-- 14,997 more properties here -->
    </entity>
    <!-- another 91.999... GB of data -->
  </data>

Now, a DOM parser - or any similar approach - would be
horridly out of place if we wanted to invoke some doFoobar
behaviour on all of our entities. A streaming parser
(expat, or something using SAX API or somesuch) would be a
much better solution. Assuming we had a clearly defined
order of elements representing properties, the processing
would be simple, fast and straightforward. We *know* what
we expect next at any point in parsing. If the order
doesn't matter, then in the middle of processing of a given
entity we may expect any of the 15,000 of them... save some
random 6,000 we've already seen for this one. Clearly, this
isn't something unsolvable, or even all that hard to solve,
but it does come with an overhead all its own.

Now consider what free order of elements gives us.
User-friendliness? Not only that is disputable, but also,
despite all appearances, XML is not really meant to be
processed by wetware. *shrug* YMMV.

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

Mine ain't any good either, so, duh.

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

I'll try to explain using your original example. Basically,
assuming you want to make sure your Content elements
contain something sensible depending on the Name element,
you cannot design a strict schema that would validate
something like:

  <TextItem>
    <Name>Temperature</Name>
    <Content>27°C</Content>
  </TextItem>
  <TextItem>
    <Content>cloudy</Content>
    <Name>Sky</Name>
  </TextItem>

...without validating:

  <TextItem>
    <Name>Temperature</Name>
    <Content>cloudy</Content>
  </TextItem>
  <TextItem>
    <Name>Sky</Name>
    <Content>27°C</Content>
  </TextItem>

as well. You *could* do the following:

  <TextItem xsi:type="temperatureType">
    <Name>Temperature</Name>
    <Content>27°C</Content>
  </TextItem>
  <TextItem xsi:type="skyType">
    <Content>cloudy</Content>
    <Name>Sky</Name>
  </TextItem>

But as I already said, that's quite clunky, and probably not
worth the trouble.

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