[GeoSciML] FW: 12-110, GML-nil

Simon.Cox at csiro.au Simon.Cox at csiro.au
Thu Nov 29 11:37:04 EST 2012

Al - 

Clemens has come in with two comments on gml-nil - both related to your contributions ;-)
The comments are clearly intended to be constructive. 

Simon Cox
Research Scientist
CSIRO Earth Science & Resource Engineering

Phone: +61 8 6436 8639 | Fax: +61 8 6436 8555 | Mobile: 0403 302 672
simon.cox at csiro.au | www.csiro.au
Address: ARRC, PO Box 1130, Bentley, WA 6102, Australia
From: requests-bounces+simon.cox=csiro.au at lists.opengeospatial.org [requests-bounces+simon.cox=csiro.au at lists.opengeospatial.org] On Behalf Of Clemens Portele [portele at interactive-instruments.de]
Sent: Friday, 23 November 2012 10:57 PM
To: requests at lists.opengeospatial.org
Subject: [Requests] 12-110, GML-nil


1. Evaluator: Clemens Portele, portele at interactive-instruments.de

2. Submission: 12-110, GML-nil


1. Requirement: gml-nil:req/UMLNillable/package, gml-nil:req/UMLNillable/import

2. Implementation Specification Section number: 7.2, 7.4

3. Criticality: Major

4. Comments/justifications for changes: "The value specified for voidableProperties SHALL apply to all class attributes and association roles in the application schema, including those defined in its dependency packages." Including imported packages essentially changes the imported packages and breaks UML (as it changes at least the value type of the properties in the imported schema). I understand why this is needed in the context of specifications that triggered GML-nil, but this should not be established as a recommended approach.

- Drop "including those defined in its dependency packages" and the <<voidable>>/<<notvoidable>> stereotypes on import dependencies from this conformance class.
- Create another conformance class which supports these manipulations of the nillable behaviour and which explains the context as well as recommends that this approach should be avoid, if possible.

1. Requirement: General

2. Implementation Specification Section number: Clause 8

3. Criticality: Editorial/Major

4. Comments/justifications for changes: GML 3.2 has a section on nillable behaviour ( Elements declared to be "nillable"). The requirements in GML-nil, clause 8 are not consistent with GML 3.2, section With the current text, the situation will be quite confusing to someone not familiar with the background of the GML-nil proposal as GML-nil creates another approach to encoding nil in data and schemas in addition to the standard approach. While in general it would be preferable to have only a single approach for encoding nil values in GML, I also see that communities may want to keep their existing approach for backwards compatibility reasons, even if this deviates from the approach in the GML standard. However, this should be done with proper guidance to avoid confusion.

- Add a statement in Clause 8 that this approach should only be followed in schemas where the standard GML approach for nillable properties specified in GML 3.2,, cannot be applied.

Requests mailing list
Requests at lists.opengeospatial.org

More information about the GeoSciML mailing list