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

Peter Parslow Peter.Parslow at os.uk
Wed Feb 25 09:28:12 EST 2015


Clemens, Richard,
Thank you for all this input. I'm learning; especially about properly conforming to GML Simple Features profile. Interestingly, none of these issues were raised in an interoperability plugfest last year, so the schema & data are clearly usable in software that supports/expects SF0.

Given that INSPIRE has published (a while back) guidance encouraging the use of wfs:FeatureCollection as the root element of GML data sets, instead of application schema specific feature collections, I expect we'll amend our schema & data at some point to do that. I may then be in the slightly odd position where 'my' schema can properly conform to SF-0, but the datasets may not - unless wfs:FeatureCollection happens to.

Peter

-----Original Message-----
From: Clemens Portele [mailto:portele at interactive-instruments.de]
Sent: 25 February 2015 11:33
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

Richard,

with all the troubles related to using derivation-by-restriction in both object and property types (partly due to XML parser issues, but also unclear wording in the W3C XML Schema spec), I think it is safer to avoid using the property type patterns as base types for custom property types. GML 3.2 has got rid of all derivation-by-restriction on property types in the GML schema as a consequence, if my memory is correct.

Clemens

> On 19 Feb 2015, at 17:47, Richard Martell <rmartell at galdosinc.com> wrote:
>
> 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
>



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


More information about the CITE-Forum mailing list