RE: [sdo] ISSUE 157: Support for Facets. Proposed PartialResolution

["Barack, Ron" <ron.barack@sap.com>]

Hi Blaise,

 

The idea of having a user error is to avoid having to talk about what happens when the user specifies a facet that is not allowed in XSD.  For instance, what happens when the user specifies a min value on a string property, and then generates the XSD.  Should the implementation generate invalid schema, should it edit out the facets, should it throw an exception?  I’d just rather get of answering this question by saying that the user shouldn’t put the implementation in this predicament, and the implementation is therefore free to do whatever it wants.  I think the trouble with specifying min and max on string properties, is that it gets us in the position of defining ordering of strings, and therefore leads to all sorts of internationalization problems, which is presumably why it was left out of the XML spec.

 

Ron

 

From: Blaise Doughan [mailto:blaise.doughan@oracle.com]
Sent: Dienstag, 26. Januar 2010 17:06
To: Barack, Ron
Cc: sdo@lists.oasis-open.org
Subject: Re: [sdo] ISSUE 157: Support for Facets. Proposed Partial Resolution

 

Hi Ron,

Not sure it needs to be a user error to apply a facet to a type that XML schema does not support that facet on (i.e.  Why not allow minExclusive, maxExclusive, minInclusive, maxInclusive on commonj.sdo.String properties?).  The table is useful for setting the expectations on what the generated schema will look like (i.e. if minInclusive is on a Integer property then it will be included in the schema gen, a minInclusive facet on a String property will not be).

For the facets MinInclusive, MinExclusing, MaxInclusive, MaxInclusive, and Enumeration should the property type be Object rather that String?

-Blaise

Barack, Ron wrote:

Hi Blaise,

 

Here is the compatibility table, which reflects the applicability of facets on the XSD.  I think we can leave it to be a user error to attach a facet to an inappropriate type, and leave to the implementations the question of how they handle the user error.

 

We can include this table at the end of section 5.4

 

 

Facet->   Type    |   V	length	minLength	maxLength	pattern	enumeration	minExclusive	maxExclusive	minInclusive	maxInclusive	totalDigits	factionDigits
Boolean				X
Byte				X	X	X	X	X	X	X	0
Character				X	X
Double				X	X	X	X	X	X
Float				X	X	X	X	X	X
Int				X	X	X	X	X	X	X	0
Long				X	X	X	X	X	X	X	0
Short				X	X	X	X	X	X	X	0
String	X	X	X	X	X
Bytes	X	X	X	X	X
Decimal				X	X	X	X	X	X	X	X
Integer				X	X	X	X	X	X	X	0
Date				X	X	X	X	X	X

 

 

I would like to modify section 8 by modifying the text (around line 2470)

 

For each Type that is a dataType, type.dataType==true, an SDO implementation MUST generate an XSD SimpleType as follows:

[NAME] is type.name

[ABSTRACT] is type.abstract.

[ALIAS_NAME] is space separated values from type.aliasNames and is produced if there are alias names.

[BASE.NAME] is the name of the base type, type.getBaseTypes().get(0).getName() if not null. When not null, the simple type extends the base type. tns: is the prefix for the URI of the base type, type.getBaseTypes().get(0).getURI(). If the base type is in another namespace the appropriate namespace and import declarations are produced by the implementation. If there are no base types, then the xsd type used is from the table "Mapping of SDO DataTypes to XSD Built in Data Types".

[FACETS] is the list of restrictions on the datatype’s values, accessed through type.get(“facets”) (for details on the facet property and the standard facet types, see section 5.4).

[FACET] is an element in the [FACETS] list.

[FACET-TYPE] is the value of [FACET].getType().getName().

[FACET-VALUE] is the string representation of [FACET].get(“value”).

[ENUM-VALUE] is an element in the list returned by [FACET].getList(“value”)

 

[COR08000005]

 

 

SDO Type	XSD SimpleType
	<xsd:simpleType name=[NAME]>
[ABSTRACT]	abstract=”true”
[ALIAS_NAME]	sdox:aliasName=[ALIAS_NAME]
[BASE.NAME]	<xsd:restriction base=tns:[BASE.NAME]>
[FACETS]     [FACET] other than enumerations     [ENUM-VALUE]	<xsd:restriction …>    <xsd:[FACET-TYPE] value=”[FACET-VALUE]” />    <xsd:enumeration value=”[ENUM-VALUE]” /> </xsd:restriction>

 

As with this text, we probably need to point out the special handling of enumerations in section 7.3.2, that is, we probably need the additional lines

 

Simple Type with non-enumeration facet   <simpleType name=[NAME]>    <restriction base=[BASE]>          <[FACET-TYPE] value=[VALUE]/>     </restriction> </simpleType>	Type name=[NAME]   dataType=true   uri=[URI]   base=[BASE]   facets=[FACET]   where [FACET] is a DataObject    type=[FACET-TYPE]    properties = {           value = [VALUE]    }   the open content “facets” property and the different FACET-TYPEs are described in section 5.4.
Simple Type with enumeration facet   <simpleType name=[NAME]>    <restriction base=[BASE]>          <enumeration value=[VALUE1]/>          <enumeration value=[VALUE2]/>          <enumeration value=[VALUE3]/>          …     </restriction> </simpleType>	Type name=[NAME]   dataType=true   uri=[URI]   base=[BASE]   facets=[FACET]   where [FACET] is a DataObject    type=Enumeration    properties = {           value = {[VALUE1] [VALUE2] [VALUE3]…}    }   the open content “facets” property and the different FACET-TYPEs are described in section 5.4.

 

 

Best Regards,

Ron

 

From: Blaise Doughan [mailto:blaise.doughan@oracle.com]
Sent: Montag, 25. Januar 2010 17:20
To: Barack, Ron
Cc: sdo@lists.oasis-open.org
Subject: Re: [sdo] ISSUE 157: Support for Facets. Proposed Partial Resolution

 

Hi Ron,

Agreed, according to section 9.2.2 in the SDO 2.1.1 spec, a new Type would be created in this case, so your proposal does not constitute a breaking change.

What changes need to be made in section 8 "Generation of XSD from SDO Type and Property"?  We'll need a table of how the SDO facets translate to XSD facets?  Also what is the behaviour if XSD cannot represent the SDO facet, presumably it is just a lossy conversion and no exception would be thrown.

For the facets MinInclusive, MinExclusing, MaxInclusive, MaxInclusive, and Enumeration should the property type be Object rather that String?

-Blaise

Barack, Ron wrote:

Hi Blaise,

 

The second point in your mail is that the proposal represents a breaking change, because in SDO 2.1 the provided schema will produce a property with type string, but in the proposal we create an anonymous type that has base type sdo:string but also has facets.

 

I disagree that this is the SDO 2.1 behaviour.  I believe an anonymous type must be created also in SDO 2.1.  Section 9.2.2 of the spec, at the top of page 85, clearly states that anonymous simple types are modeled as … anonymous simple types.  The difference is that in 2.1.1 it is more or less non-sensical to do so, since the anonymous subtype does not really add any information over the base type. 

 

Ron

 

From: Barack, Ron [mailto:ron.barack@sap.com]
Sent: Dienstag, 19. Januar 2010 16:55
To: Blaise Doughan
Cc: sdo@lists.oasis-open.org
Subject: RE: [sdo] ISSUE 157: Support for Facets. Proposed Partial Resolution

 

Hi Blaise,

 

If we don’t validate, then I don’t think we need to specify the set of simple types to which a facet can be applied.  In other words, as far as the standard is concerned, the facets are simply metadata associated with a type.  If XSD was used to define the types, they are a friendly and standard way of querying the XSD.  SDO doesn’t break even if you apply maxValue to a string, which, as you point out, could be sensible even though XSD doesn’t allow it.

 

That said, if we want to specify the simple types to which a facet can be applied, I’d probably want to follow what XSD allows (I can provide a table, if necessary).

 

 

Ron

 

 

From: Blaise Doughan [mailto:blaise.doughan@oracle.com]
Sent: Dienstag, 19. Januar 2010 16:07
To: Barack, Ron
Cc: sdo@lists.oasis-open.org
Subject: Re: [sdo] ISSUE 157: Support for Facets. Proposed Partial Resolution

 

Hi Ron,

What's missing from the core spec are what SDO types each facet pertains to.  For example it was not immediately clear to me why MinInclusive was a String property, until I remembered that it can apply to both numerical and date/time XML schema types.  Will these XML schema based facets only apply to their SDO counterparts or will I be able to state for a string property MinInclusive="apple" MaxInclusive="car", where "banana' would be a valid value while "dog" would not be?

Also should Enumeration be limited to List<String>?  I could have an enumeration of other XML schema types:

    <xs:simpleType name="prime-enum">
        <xs:restriction base="xs:int">
            <xs:enumeration value="2"/>
            <xs:enumeration value="3"/>
            <xs:enumeration value="5"/>
            <xs:enumeration value="7"/>
        </xs:restriction>
    </xs:simpleType>

This proposal introduces a backwards compatibility issue, prior to SDO 3.0 when the following XML schema was converted to SDO metadata then the "user-id" property would have been of type "{commonj.sdo}String", with this new proposal the type of the "user-id" property will now be an anonymous subtype of {commonj.sdo}String.

    <xs:complexType name="customer">
        <xs:sequence>
            <xs:element name="user-id">
                <xs:simpleType>
                    <xs:restriction base="xs:string">
                        <xs:minLength value="8"/>
                        <xs:maxLength value="10"/>
                    </xs:restriction>
                </xs:simpleType>
            </xs:element>
        </xs:sequence>
    </xs:complexType>

-Blaise

Barack, Ron wrote:

Hi,

 

Here are the modifications to the core spec.  I’m still working on the modifications to the Java spec.

 

 

Ron

 

 

 

Remove the end of section 4.4.8, starting at around line 867, the paragraph beginning “In addition to the open content properties…”

 

 

Add a section 5.4, as follows:

 

Representation of DataType Facets

SDO defines an open content property and a set of types that can be used to express the constraints on the values given to properties.  The manner in which these constraints are expressed is intended to support a straightforward mapping with facets expressed using XML schema.

Figure 5.4-1 shows the structure of the open content property and the associated facet types. The open content “facets” property, the abstract “Facet” type, and all the concrete subclasses of Facet are in the http://docs.oasis-open.org/ns/opencsa/sdo/facet/200911 namespace.  Note that, as with XML, the constraints (or “facets”) are associated not directly with a property, but rather with a type.  That is, to specify that a property can accept only strings of length 4, a type defining strings of length 4 has to be defined, and used as the type of the property.

 

 

 

 

Individal languages can extend some of the constructs defined by this core specification.  For instance, the Java specification adds a “validator” property to the abstract Facet type.  Many of the concrete facet types defined here follow the pattern that each is characterized by a single property named “value”.  The type of the value property varies, depending on the concrete facet.

An implementation of SDO MUST define the facets property, the abstract Facet type, and all the concrete types defined in table 5.4 -1 [COR05040001]

http://docs.oasis-open.org/ns/opencsa/sdo/facet/200911 type	Definition of value property
minLength	Int value
maxLength	Int value
length	Int value
minInclusive	String value
MaxInclusive	String value
MinExclusive	String value
MaxExclusive	String value
TotalDigits	Int value
FractionDigits	Int value
Enumeration	String value
Pattern	String value

 

Table 5.4‑1

Note that the set of facets defined by this spec is extensible.  Implementations and users can define additional facet types.  There is of course no requirement that all facet types follow the single “value” property pattern.

The SDO 3.0 core specification does not define any implicit validation of values given to properties.  Whether or not to perform “fail-fast” validation is left to the language specific specifications.

 

Add a row to the table in section 7.3.2

 

XML Simple Types	SDO Type
Simple Type with facet   <simpleType name=[NAME]>    <restriction base=[BASE]>          <[FACET-TYPE] value=[VALUE]/>     </restriction> </simpleType>	Type name=[NAME]   dataType=true   uri=[URI]   base=[BASE]   facets=[FACET]   where [FACET] is a DataObject    type=[FACET-TYPE]    properties = {           value = [VALUE]    }   the open content “facets” property and the different FACET-TYPEs are described in section 5.4.

 

 

Add the corresponding compliance point to the appendix:

 

COR05040001

An implementation of SDO MUST define the facets property, the abstract Facet type, and all the concrete types defined in table 5.4 -1