XSD for constraints *and* default value

[briesenberg07]

...to support use of CTRL + SPACE in oXygen

[briesenberg07]

Seems to work just fine:

See...

    <xs:simpleType name="localid_attr">
        <xs:restriction base="xs:string">
            <xs:pattern value="\S+"/>
            <xs:enumeration value="!NEED_LOCAL_ID!"/>
        </xs:restriction>
    </xs:simpleType>

...and

    <xs:simpleType name="form_order_type">
        <xs:restriction base="xs:decimal">
            <xs:minInclusive value="0.0"/>
            <xs:maxInclusive value="1.0"/>
            <xs:enumeration value="0.5"/>
        </xs:restriction>
    </xs:simpleType>

[briesenberg07]

It seems I was wrong with regard to the mixing of different xs:restriction elements, or at least with regard to the mixing of xs:pattern and xs:enumeration above:

Same goes for minInclusive + maxInclusive + enumeration--seems only enumeration is taken into account during validation:

[briesenberg07]

I'd like to do for form_order element values

[gerontakos]

Here are some jumbled thoughts, I hope they help.

I'm not entirely sure what you want to do. However, as regarding defaults, as I remember it you declare those as part of the element or attribute declaration, not as part of the type.

<xs:attribute name="fake" type="mapid_propSet_attr" **default="enter_rda_entity_here"**>

So you have to repeat the default for every element or attribute that share a common type (when they do in fact have a common default).

Default values in XML Schema have always been a mystery to me. I think it's useful for content completion when authoring an XML document based on the schema, or when deriving an XML document from an XML schema. However I haven't used it otherwise. I thought an XML Schema processor was supposed to insert a default value in the XML document when there is no value present and a default is specified; I have never seen that happen.

The problem you present is not just about default values but, rather, an exploration of simple type definitions; in particular, simple type restrictions; and even more particular, combining facets in a restriction.

In both your examples, say example 2:

<xs:simpleType name="form_order_type">
    <xs:restriction base="xs:decimal">
        <xs:minInclusive value="0.0"/>
        <xs:maxInclusive value="1.0"/>
        <xs:enumeration value="0.5"/>
    </xs:restriction>
</xs:simpleType>

...you're using xs:enumeration in an odd way. xs:enumeration in this case is used to create a set of valid values
for a simple type restriction. You created a set with one item: (0.5). This means the only valid value is 0.5. Anything else would not be valid, even if it falls between the specified minExclusive and maxInclusive, right?

I believe when minInclusive, maxInclusive and enumeration are all used together, the XML instance needs to meet all the facets specified. If the facets contradict each other, you will never be able to validate. The XML Schema document however should validate with the contradiction. I'm not totally sure about that: there are many potential areas of conflict when there's, say, a default, a base type, and multiple restriction facets. I'm not sure how these will be handled by your processor, you'll have to explore.

The xs:pattern facet also creates a set of valid values that conform to a specified regular expression. It works very much like xs:enumeration. In both cases I believe only one of the members of the set need to be matched in the XML instance.

Okay let's see where that leaves you.

I'm not sure about preventing duplicate values for a specific element or attribute, I've never done that, but I could check into it if that's part of this issue also.