Hi,
I've got the following schema code :
<xs:element name="ChoixEnumereMultiple">
<xs:complexType>
<xs:attribute
name="type" type="ChoixEnumereMultipleType" use="required"/>
</xs:complexType>
</xs:element>
<xs:simpleType name="ChoixEnumereMultipleType">
<xs:restriction base="xs:NMTOKENS">
<xs:enumeration value="choix1"/>
<xs:enumeration value="choix2"/>
<xs:enumeration value="choix3"/>
</xs:restriction>
</xs:simpleType>
And I try to validate the following instance
having two NMTOKEN separated by a space :
<ChoixEnumereMultiple type="choix2 choix3"/>
XSDVAlid answers :
attribute "type" has invalid value "choix2
choix3": "choix2 choix3" is not one of the
allowed values [cvc-enumeration-valid] [cvc-attribute.3]
It seems that this is an error because it is
possible to restrict NMTOKENS by an enumeration of values in an attribute.
Any idea of the problem ?
By the way, if someone is using other method,
feel free to tell me your solution because I'm
not fully glad with this one. What I try to de is
to find the best base type that enable either
multiple choice or single choice while defining
context usages of the enumeration.
At 10:47 03/07/2006, you wrote:
>Daniel Dekany wrote:
> > I'm using XXE 3.3.0, Sun J2SE 1.5.0_06 and 1.6 beta 2 on Windows XP.
>
>Please note that XXE has not yet been officially validated against J2SE 1.6.
>
>
>
> > The tab on the right side that shows that character table shows some
> > characters in the 0x7F-0x8F range (inclusive), but there are no visual
> > characters there according to UCS. It seems that the shown gliphs were
> > chosen based on the Windows code-page code points. The practical
> > problem coming from this is that since Windows code-pages store often
> > used things like left- and right-quotation marks and ellipsis there,
> > people will spot them and use them in the documents, add them to the
> > "Favorites", etc. But in fact they will insert some non-visual
> > characters into the XML. Then with the default font that XEE uses for
> > the document view (and *only* with that font, as far as I can tell)
> > the same bug is present, so the author will not notice that something
> > went wrong. Until (s)he generates HTML or something, that is...
>
>We'll try to fix this problem in next release.
>
>
>
> > (BTW, OT: J2SE 1.6 will support subpixel anti-aliasing (aka ClearType)
> > for text. The current 1.6 beta already does. It would be good if that
> > works in XEE... it already works for most GUI components of XEE, but
> > not on the document view somehow.)
>
>In XXE v3.3, with J2SE *1.6*, when Options|Options, General section,
>"Text Anti-aliasing" is turned on, you get:
>[a] Text Anti-aliasing in the document view.
>[b] No Anti-aliasing in the GUI: menus, dialogs, etc, on a few platforms
>(e.g. Linux non-Gnome).
>
>The [b] problem has been fixed in v3.4 (not yet released).
>
>Now, you are speaking of *subpixel* anti-aliasing. Therefore please tell
>us if the problem you report is about:
>[1] Lack of Anti-aliasing in parts of XXE.
>[2] OR you get Anti-aliasing in XXE, but not the kind of Anti-aliasing
>you would like to get.
>
>--
>XMLmind XML Editor Support List
>xmleditor-support at xmlmind.com
>http://www.xmlmind.com/mailman/listinfo/xmleditor-support
Pierre Attar (mailto:pat at tireme.fr)
Consultant en informatique documentaire XML
Consultant in Structured Document engineering
Tir?me SARL (http://www.tireme.fr)
