why do people prefer sequence to all?

[Andrew]

I have used XML for a few years now but this is the first time I have
had to create a schema. I already have written the C++ code, using
libxml2, that serialises and deserialises the messages. I just need to
define a schema for all the messages so they can (optionally) be
validated. Here is an example:

I have a CpuLoad message which contains xml:decimal for user, sys,
nice, idle, wait, total. I have defined this using xs:all with
minOccurs=1 but my colleagues say they would use xs:sequence. I have
discussed it with them and pointed them to the documentation at
http://www.w3schools.com/schema/schema_elements_ref.asp. There it says
that sequence is ordered but all is not. Sequence is zero or more but
all is zero or one. They agree that unordered and one of each is what
I want but they say they would still use sequence because everyone
else does it like that. Really? I see plently of cases on this ng
where people are using all.

I don't want to go against the flow of what people normally do when
defining schemas. Any advice please?

Regards,

Andrew Marlow

 

[Joe Kesselman]

The purpose of schemas (or DTDs) is to help define which documents are
legal. As such, they're a collaboration with the programmers who will
have to process those documents.

From a programmer's point of view, "all" is almost never the right
answer. There's usually at least some structure to the language, and
often (in data-oriented rather than document-oriented uses of XML) the
structure is very explicit. That structure makes programming much
easier, and may be tied directly to the semantics (meaning) of the language.

To take a document example: A table is made up of rows, columns, and
column documentation (headers and footers, for example). There are
several possible ways of arranging that data, but for the document to
make sense to a program you'd pick one of them and stay with it. There's
no need to permit, for example, an image which is within the table but
isn't within one of those sections -- and every reason to forbid it,
since if you allow it you have to check for it and explicitly decide
what to do about it.

Similarly, there's no reason to allow a table row to exist outside a
table, and good reasons not to. And there's no good reason to allow a
table row to be entered above the table's header line (if your language
distinguishes the two).

Take those example, and those issues, and propagate them all the way up
and down the document structure.

Yes, there are places where many different elements will be legal. But
there will always be some which would be meaningless at that point, and
eliminating them at the schema level reduces program complexity --
resulting in faster and more reliable processing.

It also reduces user confusion. "What tags are legal here" really ought
to be well-documented anyway; building it into the schema helps people
avoid writing inherently broken documents.



--
Joe Kesselman,
http://www.love-song-productions.com/people/keshlam/index.html

{} ASCII Ribbon Campaign | "may'ron DaroQbe'chugh vaj bIrIQbej" --
/\ Stamp out HTML mail! | "Put down the squeezebox & nobody gets hurt."