Rules for elements and types in a profile

Copyright © 2007 Open Geospatial Consortium, Inc. All Rights Reserved. 223  include all mandatory particles subelements and attributes of the parent element in GML.  include no particle that is not in the parent element in GML.  have the same default values for attributes as the parent element in GML.  have a parallel substitution group hierarchy for named elements in both schemas. Global types in a GML profile shall:  share the same name and namespace of a parent type in GML.  include all mandatory particles subelements and attributes of the parent type in GML.  include no particle that is not in the parent type in GML.  have the same default values for attributes as the parent type in GML.  have a parallel derivation tree for named types in both schemas. Instance documents of a profile shall be valid against the full GML schema. Using the ―copy and delete‖ metaphor described above, our mythic developer may:  delete global elements and global types.  delete optional subelements from any types or elements.  make optional subelements or attributes mandatory in any type or element if a default value exists, it shall be eliminated or the schema validation will report an error  default values are only valid for optional particles.  restrict cardinality of any particle. None of the above will affect the validity of a document that is designed against the profile, but tested against the full GML schema. Our mythic developer may not:  delete mandatory subelements from any types or elements.  make mandatory particles optional.  relax cardinality restrictions of any particle.  add or change a default or fixed value. The last item is a bit subtler than the others are. Documents valid under the profile would still be valid under the full GML schema, but the interpretation of those documents would change. For example, if a profile specified a default coordinate reference system to be UTM, and the full schema specified a WGS 84 geodesic latitude, longitude as the default CRS, then the interpretation of the file would change when moving from the profile to the full schema. 224 Copyright © 2007 Open Geospatial Consortium, Inc. All Rights Reserved.

20.5 Rules for referencing GML profiles from application schemas

A GML application schema shall reference the full GML schema in the schemaLocation attribute of the import element. A GML application schema document conforming to one or more GML Profiles shall provide an appInfo annotation element gml:gmlProfileSchema for every profile in the root schema document schema element where the value is a schema location of the profile schema. Note that an application schema may conform to multiple profiles. EXAMPLE schema ... annotation appInfo gml:gmlProfileSchemahttp:schemas.opengis.netgml3.2.1profilesgmlSimpleFeatureProfile1.1.0gmls f.xsdgml:gmlProfileSchema gml:gmlProfileSchemahttp:schemas.opengis.netgml3.2.1profilesgmlPointProfile1.1.0gmlPointProfil e.xsdgml:gmlProfileSchema appInfo annotation ... schema The gml:gmlProfileSchema element is defined as element name=gmlProfileSchema type=anyURI

20.6 Recommendations for application schemas using GML profiles

In order that the profile within an application schema may be later extended to include other profiled GML elements, the following recommendations are made:  Global elements that are not in a GML profile but are in an application schema using a GML profile should not have the same name as any element in the GML schema.  Global types that are not in a GML profile but are in an application schema using a GML profile should not have the same name as any type in the GML schema. If a type or element in an application schema is found to be of universal use, then the above conventions will aid the application schema from migrating that type or element from its own namespace to that of GML. The following recommendations are made simply as a bookkeeping convenience to those trying to understand the role of the profile in the application schema:  Profiled elements and types should be included either in a single file for smaller profile or in a file structure that parallels that of GML. The exact naming convention of the parallelism is left to the application schema author.  A reference to the appropriate GML schema document should be made in a comment near the beginning of the file. NOTE A method that has been found to be convenient is to package the required GML components into a ―stub‖ schema document called, e.g., ―gmlForApplicationDomain.xsd‖. This document may comprise a copy of the necessary components assembled in a fine-grained manner e.g. see Annex G, or may merely include a subset of the schema documents that Copyright © 2007 Open Geospatial Consortium, Inc. All Rights Reserved. 225 comprise the standard GML distribution. The schema document gml.xsd is an exhaustive superset following the latter approach.

20.7 Summary of rules for GML profiles

In summary, the rules for a profile:  A profile of GML is a logical restriction of a subset of GML.  A profile shall not change the name, definition, or data type of mandatory GML elements or attributes.  The relevant schema or schemas that define a profile shall use in the core ‗gml‘ namespace http:www.opengis.netgml3.2.  An application schema may extend and use types from the profile, but shall do so in its own namespace, and not use http:www.opengis.netgml3.2. The functional test of these rules is: Any instance document for an application schema using a GML profile will be valid against the same application schema if the GML profile is replaced by the complete GML schema. Further, the interpretation of that document would be the same regardless of which of the two schemas were used. 21 Rules for GML application schemas

21.1 Instances of GML objects

21.1.1 GML documents

An XML document contains a single XML element as its root. A GML document may be one of the following elements:  A gml:AbstractFeature or any element directly or indirectly in its substitution group. NOTE 1 This includes feature collections and coverages as both are features, too.  A gml:Dictionary or any element directly or indirectly in its substitution group. NOTE 2 This includes coordinate reference system and units dictionaries.  A gml:TopoComplex or any element directly or indirectly in its substitution group. The standard methods for XML documents based on W3C XML Schema provide that the XML namespaces used in a document are declared as attributes within the document, and the location of schema documents that provide the source components for each namespace may be indicated. For a GML document, the source of the components describing the primary components within the document is a GML application schema. Both the document type and the associated GML application schema are described in this Clause.