Working with GML Application Schemas

1. Milan Trnini},Galdos Systems, Inc.mtrninic@galdosinc.com Working with GML Application Schemas

2. Introduction • Purpose of the experiment: Analyze whether working with GML application schemas is hard/easy/feasible. • Application schema abstraction – what does it mean, what is its purpose? • Different uses of GML application schema • Information captured in GML application schemas. • API for working with GML application schemas.

3. GML Application Schemas • Intention of GML is to be base for creating applications in different domains. • This is achieved by GML and XMLSchema extensibility mechanisms. • Example of GML extension mechanism: type information in tag name. • GML occupies one level of abstraction. • Application schema is built on top of it as another level.

4. GML Application Schemas GML Application Schemas Logistical Transportation Utilities Location Service Network GML Feature Geometries Topology Other types… W3C Other types… Strings Numbers

5. Multiple Application Layers Transportation Services Route finder Route Transportation Primitives and operations Other … Intersection Event Road Segment GML Feature Geometries Topology Temporal W3C Other types… Strings Numbers

6. Class Hierarchy Feature • Objects from one layer are used to compose or create objects in a higher layer. • Use XML mechanisms: type extension substitution, sequencing, choices, etc. • Use GML mechanisms: collections, associations, feature-property model, etc. • Objects in different layers have different scope/meaning/semantics. Road Segment Intersection Event Accident Route

7. XML and GML Types GML instance <app:roadNetworkMember> <app:RoadSegment/> <gml:centerLineOf> <gml:LineString> <gml:coordinates>300.003,1234.232 306.234, 1235.090</gml:coordinates> </gml:LineString> </gml:centerLineOf> <app:otherProperty>…</app:otherProperty> </app:RoadSegment> </app:roadNetworkMember>

8. XML and GML Types GML application schema • We don’t care about XMLSchema types. • Element declarations are our GML types. <xsd:element name=“RoadSegment” type=“app:RoadSegmentType” substitutionGroup=“_Feature”/> <xsd:complexType name=“RoadSegmentType”> <xsd:complexContent> <xsd:extension base=“gml:AbstractFeatureType”/> </xsd:complexContent> </xsd:complexType>

9. GML Types Names GML instance <app:qwe> <app:XYZ/> <app:abc> <app:ASD> <gml:coordinates>300.003,1234.232 306.234, 1235.090</gml:coordinates> </app:ASD> </app:abc> <app:otherProperty>…</app:otherProperty> </app:XYZ> </app:qwe>

10. GML Types Names • GML types names in themselves do not mean anything!! GML application schema <xsd:element name=“XYZ” type=“app:XYZType” substitutionGroup=“gml:_Feature”/> <xsd:complexType name=“XYZType”> <xsd:complexContent> <xsd:extension base=“gml:AbstractFeatureType”/> </xsd:complexContent> </xsd:complexType>

11. Applications and Schemas • What do applications need from the schemas? • A piece of semantics is needed in order to know what to do with the data. Not all of it. • What is semantics? How do we find it? Set of base “primitives” used to compare artifacts and draw conclusions about them. • Semantics in schemas: type hierarchy, model (feature – property), metadata.

12. Captured “knowledge” • The “knowledge” exists in the schemas. • Different uses and types of the “knowledge”: • Information about content or structure of types • Information about types semantics – type hierarchy. • Information from the GML model – we care about this • Information from XMLSchema model - concerning schema validation

13. Semantics • Again – what do we need? • “Understanding” of arbitrary schema? • “Understanding” and processing of arbitrary features? • Understanding always comes down to very simple comparisons of strings (or other types). • Semantics by metadata – same thing.

14. Schema Validator • For this purpose all the information from the schema is needed, and it has to be interpreted correctly according to the XMLSchema specification. • XML Schema specification is fairly complex. • Validating schemas means implementing all details from XML Schema Specification (example: derivation by restriction) • Not an easy task. • Performance issues are complex (depends on the application where validator is used).

15. GML Application Schema Parser (Content Examiner) • Easier task than validating. • Some assumptions can be made: • A client application will get a valid data • If that is not the case, client can only report the error, no need to analyze it according to the XMLSchema specification. • Client is interested only in content, if available. • No need to implement the whole specification – it is ok to assume and hardcode some things. • Errors might not be very precise.

16. Uses of GML Application Schema Parser • In all standard applications that use GML data such as map portrayal applications, geocoders, gazetteers, etc. • GML data editors that provide content guidance. • GML application schema editors that provide content guidance. • Applications for mapping of different data models. • Hard to remodel existing schemas.

17. Code Example Vector getFeatures(Document gmlData) { Vector result; NodeList nodes = gmlData.getDocumentElement().getChildren(); for (int index = 0; index < nodes.getLength(); index++) { Node property = nodes.get(index); boolean isFeatureMember = _schemaParser.isFeatureMember(property); if (isFeatureMember == false) continue; Node value = property.getFirstChild(); boolean isFeature = _schemaParser.isFeature(value); if (isFeature == true) result.add(value); } return result; } boolean isFeature(Node node) { return ((getSubstitutionGroup(node) == “_Feature”) && (getBaseType == “AbstractFeatureType”)); }

18. Multiple Application Layers <app:roadNetworkMember> <app:RoadConstruction/> <gml:centerLineOf> <gml:LineString> <gml:coordinates>300.003,1234.232 306.234, 1235.090</gml:coordinates> </gml:LineString> </gml:centerLineOf> <app:otherProperty>…</app:otherProperty> </app:RoadConstruction> </app:roadNetworkMember> • This means only little more work for the parser – complexity is linear! <xsd:element name=“RoadConstruction” type=“RoadConstructionType” substitutionGroup=“RoadSegment”/> <xsd:complexType name=“app:RoadConstructionType”> <xsd:complexContent> <xsd:extension base=“app:RoadSegmentType”/> </xsd:complexContent> </xsd:complexType>

19. GML Application Schema Parser API • Content retrieval • getFeatures • getGeometry • getProperties • allowedFeatures • allowedProperties • allowedGeometries • etc. • Type functions • isFeature • isFeatureMember • isGeometry • isOfType • etc . • Miscellaneous • getCardinality • etc.

20. GML Level of Abstraction • Work with features, geometries, feature members etc. • Not concerned about XMLSchema types, elements, etc. • Use the same paradigm and model with different data description languages (RDF, …).

21. Performance • Verbosity of XML/GML. • Use of existing tools. • Schema parser data model – new DOM, tables and arrays. • Solutions overlap with the ones regarding any XML processing. • Not a bigger issue than processing of instance documents (example - processing of Simple Xlinks).

22. Summary • Extensibility and semantics on the level of the application schemas achieved using simple methods – type extension. • Validator needs to perform deep and extensive analysis of the schema – it has to follow the specification which can be (and often is) complex. • Content examiner needs to follow type hierarchy, metadata information etc., which is simple – comparable to processing instance documents. • Physical complexity of schemas is not the same as the complexity of XMLSchema specification and except for the basics does not mirror it.

23. References • XMLSchema specificationhttp://www.w3c.org/TR/xmlschema-0/ • GML 2.1 specificationhttp://www.opengis.net/gml/02-009/GML2-11.html • Schema Infosethttp://www.research.ibm.com/XML/schema/WD-XML-Schema-Infoset-API-Req.htm • GML model (specification, papers) • GML4Jhttp://gml4j.sourceforge.net