-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
XSD for constraints *and* default value #6
Comments
Seems to work just fine: See...
...and
|
It seems I was wrong with regard to the mixing of different Same goes for |
I'd like to do for |
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.
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:
...you're using xs:enumeration in an odd way. xs:enumeration in this case is used to create a set of valid values 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. |
Possible to assign default |
...to support use of CTRL + SPACE in oXygen
The text was updated successfully, but these errors were encountered: