#5 <xs:all> doesn't work
I use such element definition:
----------------------------------------------------------
<element name="table">
<annotation>
<documentation>
Таблица включает в себя описание и сами данные.
</documentation>
</annotation>
<complexType>
<all>
<element ref="arcl:titleabbrev" minOccurs="0" maxOccurs="1"></element>
<element ref="arcl:title" minOccurs="0" maxOccurs="1"></element>
<element ref="arcl:info_url" minOccurs="0" maxOccurs="1"></element>
<element ref="arcl:tbody" minOccurs="1" maxOccurs="1"></element>
</all>
</complexType>
</element>
----------------------------------------------------------
XSchema validation check a document using this rule correctly. But Jaxe doesn't take it into account. It behave as if minOccurs="0" and maxOccurs="*". I can add internal tags many times.
Logged In: YES
user_id=56791
Originator: NO
Jaxe's home page states :
"Jaxe does not support all the features of XML schemas. To know exactly what Jaxe supports, look at the file config/SimplerSchema.xsd: it's a subset of the schema for schemas including what Jaxe understands."
The all group is not in SimplerSchema.xsd, so it is not supported by Jaxe. In other words, this is a feature request, not a bug.
The problem to implement this in Jaxe is that Jaxe is using regular expressions to check validity in real-time. A regular expression for the elements a, b and c in an all group would be : abc|acb|bac|bca|cab|cba
It does not scale well, and so far I have not found a solution. As you noticed, Jaxe is currently using (a|b|c)* instead.
However, I just had an idea : maybe I could simply use the "abc" regular expression, and then make sure when I build the test expression that elements are ordered in the same way as in the schema. This would would slow down real-time validation a bit because Jaxe would have to check the content model every time a test expression is built, but it's worth a try...
Logged In: NO
I started to use <xsl:all> after i found that users have problems in searching place where they can insert important element. They know that they should insert it but thet can not find place. They think that it is a bug and feel thyself unhappy :) . So tag <xsl:all> could be good solution in their situation. They anticipate that behaviour ("all" tag). Moreover i found myself situation when Jaxe could not insert valid tag even in "sequence" mode (i'm not shure i can describe the path now).
On the other hand i can't imaging how can be possible to solve problem with <xsl:all> by using only regular expression quickly and in common case (may be because i don't understand methods you use). As for me i don't think regular expression in that cases is a good path (they so slow and have bounded functionality). Anyway IMHO should be door to do sometimes checks in other maner. May be i am mistaken.
Logged In: YES
user_id=1074288
Originator: NO
I also anticipated user problems with the "sequence" tag and therefore wanted
to use "all" instead. However, I encountered the same problem as this reported
bug report. Any progress in fixing it?
Logged In: YES
user_id=56791
Originator: NO
This feature is still not supported. I did a quick evaluation, and it would add a lot of complexity to schema real-time validation in Jaxe, so I haven't done it yet.
I don't think it's a good solution to the problems with the sequence element, because xs:all has some severe limitations. So we still need sequences, and I don't think it's possible to avoid explaining what a sequence is to users. Also, I think this is a UI problem if users don't understand how to use a sequence. To help users understand what elements they can use at a given place, I added disabled buttons in the insertion panel for the elements authorized under a parent, but that cannot be inserted because of sequence rules. Moving the cursor over the disabled button explains the problem and gives the regular expression for the parent (in a tooltip). This is not a perfect solution, but I hope it will help a little bit.