[CITE-Forum] GML 3.2.1 application schema test: surprise failure

Richard Martell rmartell at galdosinc.com
Thu Feb 19 13:07:40 EST 2015


Hi,

With this completely backwards-compatible refactoring the schema validates using the latest revision of the GML test suite.
Note that I replaced the anonymous property type with os:TerrainContourMemberType, but the content model is unchanged.

<complexType name="DataSetType">
    <complexContent>
      <extension base="gml:AbstractFeatureType">
        <sequence>
          <element name="metadata"/>
          <element name="nominalScale"/>
          <element name="elevationReference"/>
          <element name="equidistance"/>
          <element name="member" type="os:TerrainContourMemberType" minOccurs="0" maxOccurs="unbounded"/>
        </sequence>
      </extension>
    </complexContent>
  </complexType>

  <complexType name="TerrainContourMemberType">
    <complexContent>
      <restriction base="gml:InlinePropertyType">
        <sequence>
          <choice>
            <element ref="os:LandWaterBoundary"/>
            <element ref="os:SpotHeight"/>
            <element ref="os:ContourLine"/>
          </choice>
        </sequence>
        <attributeGroup ref="gml:OwnershipAttributeGroup"/>
      </restriction>
    </complexContent>
  </complexType>


But it still does not conform with GMLSF. To conform at SF-1, introduce an abstract feature as the property value and have the features substitute for it.

e.g.
<element name="SpotHeight" type="os:SpotHeightType" substitutionGroup="os:AbstractTerrainContour"/>


 -- Richard


-----Original Message-----
From: CITE-Forum [mailto:cite-forum-bounces at lists.opengeospatial.org] On Behalf Of Richard Martell
Sent: Thursday, 19 February, 2015 08:47
To: Clemens Portele
Cc: Peter Parslow; cite-forum at lists.opengeospatial.org
Subject: Re: [CITE-Forum] GML 3.2.1 application schema test: surprise failure

Clemens,

Perhaps an explicit restriction of gml:InlinePropertyType would be more appropriate here:

<xsd:complexType name="DataMemberType">
    <xsd:complexContent>
      <xsd:restriction base="gml:InlinePropertyType">
        <xsd:sequence>
          <xsd:choice>
            <xsd:element ref="tns:AlphaFeature"/>
            <xsd:element ref="tns:BetaFeature"/>
          </xsd:choice>
        </xsd:sequence>
        <xsd:attributeGroup ref="gml:OwnershipAttributeGroup"/>
      </xsd:restriction>
    </xsd:complexContent>
  </xsd:complexType>

Introducing an abstract head element would also work (e.g. TerrainContourFeature), which is a very common GML convention.

However, the schema claims conformance to GMLSF (10-100r3) at Level 0, which is _impossible_ with such a construct.
And even at Level 1 it would run afoul of the constraints stipulated in 9.3.3; introducing an abstract head element as suggested above would probably suffice for SF-1 compliance. 


-- Richard


-----Original Message-----
From: Clemens Portele [mailto:cportele at gmail.com] On Behalf Of Clemens Portele
Sent: Wednesday, 11 February, 2015 14:23
To: Richard Martell
Cc: Peter Parslow; cite-forum at lists.opengeospatial.org
Subject: Re: [CITE-Forum] GML 3.2.1 application schema test: surprise failure

Hi Richard,

in my view the test is too strict. I recognize that "pattern" may not be a perfectly clear term in this context, but the intention was that any schema component whose instances would match also <any namespace=”##any”/>  would be ok. That would include a choice of explicit feature elements.

This intent is also explicit in 7.2.3.3 which states that "applying the pattern to define an application schema specific property type allows to restrict the inline object to specified object types, [...], the encoding to 'inline only'", which is exactly what the os:DataSetType in the application schema does.

Best regards,
Clemens
 

> On 11 Feb 2015, at 21:58, Richard Martell <rmartell at galdosinc.com> wrote:
> 
> Hi Peter,
> 
> That test is informed by the constraints laid out in the GML 3.2.1 spec. According to cl. 9.9.1, os:DataSetType is a feature collection where the distinguishing property is os:member.
> 
> Now, cl. 9.9.2 stipulates that:
> 
> "The derived property type shall follow one of the patterns specified in 7.2.3 and may set the multiplicity of the objects in the collection as required for its intended use."
> 
> So which of these patterns does it cleave to?
> 
> * 7.2.3.3: abstractAssociationRole, AssociationRoleType
> * 7.2.3.7: abstractReference, ReferenceType
> * 7.2.3.8: abstractInlineProperty, InlinePropertyType
> 
> Given the absence of XLink attributes, the last one (gml:InlinePropertyType) applies. See the examples in cl. 9.9.1.
> 
> The failing assertion flagged the use of the xs:choice compositor here; a xs:sequence was expected per 7.2.3.8 (InlinePropertyType):
> 
> <complexType name="InlinePropertyType">  <sequence>
>    <any namespace="##any"/>
>  </sequence>
>   <attributeGroup ref="gml:OwnershipAttributeGroup"/>
> </complexType>
> 
> Now, restricting this base type is not required, but adhering to the pattern is taken to mean mimicking the type definition: 
> pruning optional schema components if desired and substituting for the mandatory ones (xs:any in this case).
> 
> This is a fairly strict interpretation, but it also reflects the rules for user-defined complex property types in GMLSF-1 (OGC 10-100r3, A.10.12.3).
> 
> NOTE 1: The schema declares compliance with GMLSF-0, but it does not 
> since user-defined complex property types are not permitted at this level. Nor does it comply with 8.4.2 (Defining feature collections--see NOTE 2).
> 
> NOTE 2: The "feature collection" described in GMLSF, 8.4.2 is just a 
> generic container and does not qualify as a GML feature (it cannot substitute for gml:AbstractFeature).
> 
> 
> Hope this sheds some light on that rather cryptic error message.
> 
> -- Richard
> 
> 
> -----Original Message-----
> From: CITE-Forum [mailto:cite-forum-bounces at lists.opengeospatial.org] 
> On Behalf Of Peter Parslow
> Sent: Monday, 09 February, 2015 02:45
> To: cite-forum at lists.opengeospatial.org
> Subject: [CITE-Forum] GML 3.2.1 application schema test: surprise 
> failure
> 
> Hi,
> I've just run one of my product schemas through the r17 tests, and got an unexpected failure.
> 
> The message is
> 
> <!-- hasFeatureComponents -->
> <test-method duration-ms="0" finished-at="2015-02-09T05:27:55Z" name="verifyFeatureMemberProperties" signature="verifyFeatureMemberProperties()[pri:0, instance:org.opengis.cite.iso19136.components.FeatureComponentTests at 74862cef]" started-at="2015-02-09T05:27:55Z" status="FAIL">
>        <exception class="java.lang.AssertionError">
>                <message>Expected sequence compositor in non-empty property type {http://namespaces.ordnancesurvey.co.uk/elevation/contours/v1.0}member. expected [1] but found [2]</message>
>        </exception>
>        <!-- java.lang.AssertionError -->
>        <reporter-output></reporter-output>
> </test-method>
> 
> Which doesn't help me understand what the test thinks is wrong.
> 
> I rang the test using this URL:
> 
> http://cite.opengeospatial.org/teamengine/rest/suites/gml32/3.2.1-r17/
> run?xsd=http://www.ordnancesurvey.co.uk/xml/terrainschema/contours/v1/
> OSTerrainContourProducts.xsd
> 
> The declaration of 'member' is within the declaration of DataSetType.
> 
> Any advice would be appreciated.
> 
> Thanks
> 
> Peter
> 
> 
> 
> This email is only intended for the person to whom it is addressed and may contain confidential information. If you have received this email in error, please notify the sender and delete this email which must not be copied, distributed or disclosed to any other person.
> 
> Unless stated otherwise, the contents of this email are personal to the writer and do not represent the official view of Ordnance Survey. Nor can any contract be formed on Ordnance Survey's behalf via email. We reserve the right to monitor emails and attachments without prior notice.
> 
> Thank you for your cooperation.
> 
> Ordnance Survey
> Adanac Drive
> Southampton SO16 0AS
> Tel: 03456 050505
> http://www.ordnancesurvey.co.uk
> _______________________________________________
> CITE-Forum mailing list
> CITE-Forum at lists.opengeospatial.org
> https://lists.opengeospatial.org/mailman/listinfo/cite-forum
> _______________________________________________
> CITE-Forum mailing list
> CITE-Forum at lists.opengeospatial.org
> https://lists.opengeospatial.org/mailman/listinfo/cite-forum

_______________________________________________
CITE-Forum mailing list
CITE-Forum at lists.opengeospatial.org
https://lists.opengeospatial.org/mailman/listinfo/cite-forum


More information about the CITE-Forum mailing list