[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 Everyone, I posted a draft of section 5.4, on facets, here: http://www.oasis-open.org/apps/org/workgroup/sdo/download.php/36313/Draft%20Section%205.4.doc Other changes are described earlier in this thread, namely, 1.
the change to chapter 8 2.
the changes to section 7.3.2 3.
the 2 compli1nce points added
to the appendix 4.
Remove the end of section of
4.4.8, starting around line 867, the paragraph beginning “In addition to the
open content properties…” Validation is also mentioned in section 4.1.14, but I believe
this section can be left as is. Hopefully we can resolve this in tomorrow’s meeting. Ron From:
Blaise Doughan [mailto:blaise.doughan@oracle.com] Hi Ron,
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]
Hi Ron, 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
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”)
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
Best Regards, Ron From:
Blaise Doughan [mailto:blaise.doughan@oracle.com]
Hi Ron, 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: 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]