Re: LC-16 ( LC-132 ): Allow arbitrary order with occurrence > 1

Hello Martin,

In summary, I have to say that I'm not at all satisfied with the
decision of the WG, and even less by the justification given below.

At 00/10/09 08:23 +0100, Martin Gudgin wrote:
>Dear Martin Duerst and Dan Rupe:

>Among other issues, the two of you independently raised the point
>registered as issue LC-16 ( Dan yours was originally classified LC-132 ),
>which suggests that XML Schema provide a mechanism for allowing arbitrary
>order of elements with occurence greater than one.
>
>I'm afraid the working group declined to provide such functionality on three
>grounds;
>
>
>1.    complexity for schema processors

It's a simple matter of counting, isn't it? I don't understand why
this should be difficult. For the current version of the all group,
a bit vector is needed to check that each element does occur according
to the occurrence constraints. This has to be bumped up to a vector of
integers. My guess is that this would take a few minutes in XSV, in fact
it may be easier to implement from scratch, because there are no special
restrictions on minOccurs and maxOccurs.

If there is something I have missed, please tell me.


>2.    the fact that the interpretation usually desired is incompatible with
>that of SGML's ampersand connector

I'm not sure I understand that. The all group is already different from
SGML '&' anyway. And the interpretation is straightforward. The main
simplification is provided by the fact that an all group can only
occur directly in an element, without any children groups.
I'm not at all suggesting to change that.


>3.    the feeling on the part of some WG members that this is not a pattern
>of document design to be recommended or supported.

There are definitely many cases where such a pattern is not desired.
But there are definitely also cases where it's very helpful to have
them. A typical example is metadata, e.g. the HTML <head> element.
There, the <title> element can appear only once, the <meta> element
can appear many times, and so on. The same thing can be expressed
without this feature, but the resulting content models get clumsy
and error-prone. For an example, please see
http://lists.w3.org/Archives/Public/xmlschema-dev/2000Aug/0017.html.
For another example, please see
http://slow1.w3.org/TR/xhtml-modularization/dtd_module_defs.html#a_module_Base:
<!ENTITY % head.content
     "( %HeadOpts.mix;,
      ( ( %title.qname;, %HeadOpts.mix;, ( %base.qname;, %HeadOpts.mix; )? )
      | ( %base.qname;, %HeadOpts.mix;, ( %title.qname;, %HeadOpts.mix; ))))"
 >

It is obvious that such things can be avoided for new designs, but
it is questionable that this is always desirable, because it is
a burden for an user to learn an arbitrary element sequence.

Also, it is not clear to me why the current all group is considered
a recommended or supportable design, whereas the changes I propose
are not.


>It would be helpful to us to know whether you are satisfied with the
>decision taken by the WG on this issue, or wish your dissent from the
>WG's decision to be recorded for consideration by the Director of
>the W3C.

I not only wish the dissent to be recorded, I wish the decision to
be better explained and if possible reverted.


Regards,   Martin.

Received on Wednesday, 11 October 2000 04:39:04 UTC