[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [sdo] ISSUE 157: Support for Facets. Proposed PartialResolution
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] 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] Hi Ron, 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: 4.
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]
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
Add
the corresponding compliance point to the appendix:
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]