Input to the GML 4 workshop

The comments made on this public wiki have been summarized (as of Sept 18, 2011) according to the following categories (bottom of this page).

• Linking
• Modularization & Profile Support
• Alternate encodings and compatibility areas to consider
• Complexity
• Tool Support
• Extensions
• Stability/backwards compatibility

SummaryOfPublicComments.ppt

-- DavidBurggraf - 19 Sep 2011

---

The OGC and the GML Working Group invites interested parties to attend an open, one-day workshop on GML 4 on September 19th in Boulder, Colorado.

A number of GML change requests have been submitted to OGC. Several of them would require a non-backwards compatible revision, if approved, i.e. GML 4. Many communities use the current versions of GML and creating a new version that is not backwards compatible should be done with care, if at all. Before starting work on GML 4, the GML Working Group wants to have a clear idea, if there is demand for such a version, and what the goal and characteristics of this new version should be.

To support the preparation of the workshop, you are encouraged to provide statements in advance, outlining your opinion on the subject, for example on key features of GML 4 that would justify developing and publishing a new version of GML (or not), or on the proposed modularization of GML into multiple namespaces, making it easier to pick and choose parts of GML that are relevant in a certain community or application.

Please add any thoughts and statements at the end of this page and "sign" it.

To edit this page, you need to register on the OGC Wiki. If you do not want to register, you may also send an email to portele(at)interactive-instruments.de and I will add your statement to this page.

Many thanks for your input!

Other links:

• Approved versions of GML
• GML 3.3 draft

-- ClemensPortele (Chair of the GML Standards Working Group) - 20 Jul 2011

---

Probably the most significant proposal that could not be dealt with in 3.3 is the suggestion to break GML up into multiple XML namespaces.The main reason for this would be to enable applications to conform to standard subsets, enforced through XML Schema validation mechanisms. This is also consistent with OGC's Modular Specifications policy, which aligns XML namespaces with specification modules.

However, there would be both technical and social challenges with this approach. An important technical challenge would be to determine the boundaries of the namespaces. For example: would we want geometry partitioned according to topological dimension (0-D, 1-D, 2-D, 3-D) or simple-geometries (points, lines, polygons) vs. more complex geometries (aggregates, solids, non-linear interpolation, etc). Probably both, but the combinations could lead to dozens of conformance classes/namespaces.

Which raises the principal social challenge: too many namespaces can be bewildering. IMHO it is still worth it, but we need to be very clear about why we are doing it, and also to be clear that trading one style of complexity for another can be a good thing if it has the right compensating benefits. Furthermore, the 'complexity' of GML in either flavour is because it does a lot, and is not out of line with complexity in the other software systems that have large numbers of dependencies.

-- SimonCox - 25 Jul 2011

---

An issue we may consider is whether it is possible to make GML more compatible with web trends that have emerged subsequent to the design of GML 3 (remember: GML 3.0 was developed in 2001-2, and 3.1, 3.2 and 3.3 are all based on the same foundation).

For example, xlink never took off in any community other than GML, and meanwhile, after a slow start, RDF is the basis for many contemporary applications and architectures. Nevertheless, GML applications are almost perfect RDF/XML, and could be made so by replacing @xlink:href with @rdf:resource and gml:identifier with @rdf:about. GML applications could become immediately compatible with the semantic web with this one tweak.

Another thing to consider would be greater compatibility with Atom - GML Feature Collections could be implemented as atom:collection.

-- SimonCox - 25 Jul 2011

---

Determining the most useful boundaries for GML namespaces would indeed be a challenge. Should we have one slim core GML namespace that would correspond to the Simple Features profile? This could work more or less the same as with CityGML. Users could import the GMLcore and any additional modules they need.

Or should the GML namespaces be more finegrained and would the Simple Features profile be one of the GML subsets, a composition of the most common components?

If we make very small components that each live in their own namespace, the good thing would be that the GML standard would allow very flexible use; everybody could pick and choose what they need. But there would be a lot of namespaces and we would, for example, have to be very creative in coming up with short namespace prefixes for them all. One big problem I see is there are probably a lot of dependencies between components that would end up in different GML namespaces; when we set to determining the namespace boundaries we should have a clear picture in advance of what the dependencies are and how valid subsets can be created without missing definitions on the one hand or lots of repeating of even circular imports of definitions on the other.

Whatever we end up with, in my opinion it is very important we make sure that schema validation using a wide range of parsers is possible against a GML subset.

-- LindaVanDenBrink - 28 Jul 2011

---

For me a clear separation between the encoding of features and the encoding of geometry would be interesting. In extrema I would suggest to create a separate standard for the encoding of geometries that does not mention the word Feature. I understand that this goes a bit further than putting the geometries in a separate namespace or schema but for many people that only need to encode a point or a polygon it would save a lot of time.

Shortly after posting my comment Ron has an interesting blog (http://www.galdosinc.com/archives/1203) on features and I fully agree with him that features are needed. However other frameworks have concepts that are similar to a feature (e.g. thing in linked data, Resource in rdf) but these frameworks usually lack a geometry type. By putting the geometry stuff in a separate standard it will be easier for these frameworks to reuse the good work that had been done in OGC.

-- WilkoQuak - 2011-08-10

---

For me I am in favour of almost anything that would make GML less complex and bulky, or at least to have options to use simple subsets. I see many users scared away from GML because of these issues, resorting to simple encodings like Atom, GeoRSS, GeoJSON etc. In particular within AJAX-based webapps the use of GML is painful. IMHO following current webtrends like these and maybe RDF should be considered. The above commenters already made suggestions that would support such directions: modularity, namespaces, geometry-only subsets and I agree. Maybe even alternate encodings apart from XML like JSON could be considered.

One primary example where complexity may be reduced is the encoding of geometries, for example it should be possible to encode a Point in just a single element like <Point x=.. y=.. [srs=EPSG:N..] /> i.s.o. multiple nested elements that do not add semantics. While GML is very precise in every encoding of elements, when it comes to coordinate collections, these are just slabs of element text. This makes parsing into data structures and transformations like when using XSLT very hard when having to do custom text-parsing on coordinate element texts. Simple attribute based encodings should also cater for the most common interworking problems I encounter: SRS encoding and axis-ordering. Having at least 3 encodings for SRS name seems ridiculous and leads to many headaches. I know axis-ordering is not a simple issue and everyone is always right from their PoV but I would welcome any addition to GML to specifically denote axis-ordering.

-- JustVanDenBroecke - 17 Aug 2011

---

Integration and advancement of coverages (in GML 4 possibly as an extension) appears to be an important issue. Both SWG and WCS.SWG had agreed to see the GML Application Schema for Coverages as a basis for further development, and now seems like a good time to start joint discussions. This even more as both groups apparently have ides for further functionality. Sample questions include rethinking the coverage hierarchies (in particular: the distinction between discrete and continuous coverages), servicing Multi*Coverages, continuing the refinement of the CoverageFunction semantics, adding additional coverage representations like domain/range interleaved encodings. Further, some cross-cutting issues like CRS handling (including parametric and ad-hoc combined CRSs) are highly relevant for coverages as well. Finally, the question of harmonizing observation and coverage modeling has popped up in several occasions and might be a good candidate for GML-level inspection.

As I will convene the WCS.SWG and Coverages.DWG meetings (14:00-16:00) by telecon, is it possible to have a GML 4 coverage discussion sometime in the morning, allowing me to join in by telecon?

-- PeterBaumann - 29 Aug 2011

---

I have used GML in a project with a software company (Key Traffic Systems) building a WFS for their traffic engineering data. I found the experience rather interesting, in the sense that while GML3.x is pretty complete we really needed very little of it, and found that most WFS clients that their users had available (Arc or MapInfo mostly) actually have pretty limited real support for GML and WFS. In the end we used mostly GML2.x.

Another issue was that styling was not possible. I can see the logic of separating presentation from content, but this is a tricky thing in practice (SLD is not supported widely at all in reality).

In the end we used KML for simple applications and had to build our own Arc client which bypassed OGC services to get the required functionality (simply correct rendering in the first instance with styling applied).

So if I was to ask for things in GML4 the first would be client support (and complete, working support) and the second would be as simple as possible modularity with some well defined ‘profiles’ so you know what is supported. I’d also like to see more emphasis on usability and less on complex data models – bear in mind what it is really being used for.

Finally I’d like to see less XML! It just doesn’t scale in practice. Support for compressed XML is still not universal, and no sane person would actually read an XML file – why not go binary or maybe JSON for browser support? You can keep the data model consistent … these are just encodings …

While that does sound negative I’d much prefer to use GML … I’m now working in my own company with a GIS related aspect (of Oil and Gas consultancy), and no client has asked for GML yet – they all want shapefiles … so there is still a lot of work to do to make GML actually used … widely. I really do think there are two aspects – simplicity and tool / software support.

-- DanCornford - 30 Aug 2011

---

The input in this section is entered by me on behalf of those involved in the Top10NL standard , the dutch standard for small-scale topography (by the Cadastre).

The cadastre used to offer different file formats for Top10NL files, such as shape or DGN. For some time now, however, the main file format has been GML 3.1.1 and the only alternative FGDB. Most users could not work with the GML files, but this was mainly due to lack of knowledge: they were not familiar with or had never even heard of GML. Another reason they were not able to use GML was that their software could not import the Top10NL GML format easily. They would, for example, use the quick import feature of ArcGis, which caused problems because it did not deal correctly with multiple occurrence of attributes and objects having more than one geometry. Users would find that some of the data did not end up in their database and would stop their effort to import GML at all; they did not have enough knowledge to transform the GML correctly themselves. It was found, however, that there is sofware available that makes it easy to create such a transformation. This helps the category of users who have a (GIS) database they want to load the Top10NL GML into, but doesn't help other users, who have a CAD system.

To help user acceptance of the Top10NL GML format the Dutch cadastre is stimulating Dutch software vendors to build conversion tools for easy Top10NL-GML to GIS and possibly Top10NL- GML to CAD import.

All this does not point to specific problems with the GML standard, but mostly to lack of familiarity with the standard and lack of software support.

Based on their experience with the GML standard, the Top10NL people are very much in favour of modularization. Their input on this topic is:

• Standard profiles should be available that combine the modules necessary for a certain application domain;
• It should be easy for a user to select the appropriate profile based on what its intended application is and what it does and doesn't contain (i.e. this should be well documented);
• The modules should be created with their application domain in mind, i.e. the division into modules should be done based on usage situations. For example, an AbstractSurface in the current GML standard is a very generic container which allows vector-based surfaces but also TINs, point clouds etc. Most applications of GML will not need all those varieties at once. It would be better to have modules at a more specific level, and base the modules and profiles on applications such as vector data, raster data, 3D. Users who need to could always combine different modules.
• There should at least be a simple features profile.
• It is important to be able to validate against a 'profile' which is a combination of one or more 'modules' in a standard and easy manner: with a standard XML schema parser such as is to be found in common XML editors.

-- LindaVanDenBrink - 08 Sep 2011

---

Some more thoughts by me.

• I would be in favour of Simons idea of adopting RDF for linking instead of xlink.
• There should be a clear positioning of GML and KML and we should discuss possible further harmonization of the two. Having overlapping standards within one standards organization is confusing and should be avoided.

-- LindaVanDenBrink - 12 Sep 2011

---

• Module split

From a software implementation point of view, Luciad is in favor of a more modular GML. The biggest advantage that we see would be that different modules can evolve at their own pace. This should allow for a very stable core part of GML that needs little updates. Parts that are more evolving and/or still in a early phase (3D, temporality, coverages,...) can have their own modules, so they can go through a few iterations at a faster pace. Candidates for the core of GML would include 2D geometries and the feature concept.

We also support the idea of reducing the complexity and making it more easy for lightweight applications to support GML (or a part of it). In this context, it could be interesting to introduce a lightweight core module that (for instance) matches with the Simple Features profile.

• Measures improvements

Related to the module split, it would be interesting to have a separate module for measures, for the same reason described above. From a technical point of view, the separation of measures seems feasible, because of the limited inter dependencies with the rest of the model.

We also see a number of useful improvements for the measures part to enable applications schemas such as AIXM and WXXM define their own measure types (next to the default ones in GML). More specifically, the following improvements would be useful:
1. A dictionary system for unit of measures (UOMs) that can be extended with new ones;
2. The possibility to use non-numeric values such as Strings; for instance, AIXM 5 uses 'UNL' as value to represent an unlimited airspace height.

• XLinks

Regarding the proposal to switch to RDF for XLinks, it would be good to clearly evaluate the current issues with XLinks and the reason why a switch to RDF would solve this. Based on our experience, a lot of applications on the client and server side are not yet able to deal with external references of any type. The main reason for this is that this is seldom a requirement; additionally, the data formats that do use these concepts (AIXM 5, WXXM are still in an early stage. It could therefore be interesting to spend more time to see in which direction this should go. Internal links that use gml:id (e.g. href="#mygmlid") have been used successfully and we see no direct reason to change this.

One useful requirement for links was identified in the AIXM 5 XLink guidance document developed by Eurocontrol: it defines two types of links.
1. Abstract links that take a fixed form to reference a feature by its gml:identifier, but which can not be resolved directly;
2. Direct links in the form of a URL, which can be resolved directly.
The advantage of the abstract link is that it will always be unique and the same for a given feature; the advantage of the link by URL is that it can actually be resolved without requiring pre-knowledge. Both types have their uses, but the current specification only allows one of them to be present. It would be useful if one can specify both at the same time.

-- RobinHoutmeyers (on behalf of Luciad) - 16 Sep 2011

---

Since version 3.0 GML has been a trade-off between simplicity and scope that has attempted to balance the minimal requirements of simple use cases such as static 2-D features with linear geometries, no temporal aspects, and no topology against the more extensive requirements of complex use cases such as 3-D features with non-linear geometries, temporal geography, topology, coverages, specialized reference systems, and formal observations. Specialized profiles of GML can help with this problem, but a separate primer or tutorial is needed to support each profile, such as the one for simple features. Multiple high-level topic namespaces (e.g. core, geometry, temporal, topology, feature, coverage ...), might help comprehension, but ones at the very detailed level of granularity required to achieve the goal of creating a completely modular specification are liable to create a thicket of confusion.

The barriers to GML adoption go beyond the scope and complexity barriers to user comprehension to include limitations of existing software environments that must be augmented to achieve support for GML as a conceptual schema language and encoding mechanism. For example, GML is on one (object model) side of the well-known object-relational mismatch problem, and most geospatial data stores are on the other (relational data base management system). So a feature model in GML that has multi-valued properties or many-to-many associations is "too complex" for some GIS systems, even though join tables are a well known RDBMS design pattern that could be applied to solve the problem.

Middleware tools in particular programming environments (e.g. Hibernate for Java) address the problem in general, but (apart from 08-109_GML_CR_-_encoding_rule_for_association_class.doc which addresses part of the issue at the GML-to-UML level) there are no well-documented GML-specific design patterns or tools. The next step to address this problem and to enable development of such tools is to create model-matching encoding rules between GML and other data encoding environments, either as additional Annexes to the GML standard, or as separate implementation guidance documents.

In particular:
1) for Web applications, especially once support for HTML5 becomes widespread, model-matching encoding rules are needed between GML and JSON that go beyond what has already been achieved by GeoJSON.
2) for bandwidth constrained environments, model-matching encoding rules are needed between GML and binary formats such as Google's Protocol Buffers (http://code.google.com/p/protobuf/)

If GML4 is undertaken, it is a new point of departure at which existing GML application schemas from large organizations and extensive user communities should be examined for extensions that may be more widely applicable and worthy of consideration as source material for change requests. In particular I'd recommend Time Space Position Information ((TSPI), see http://www.gwg.nga.mil/documents/TSPI_v1_0_1.doc) and its treatment of

• accuracy The closeness of agreement between a test result or measurement result and the true value. [ISO 6709:2008]
• precision A measure of the repeatability of a set of measurements. [ISO 6709:2008]
• resolution The coordinate unit associated with the least significant digit of a coordinate. [ISO 6709:2008]
• uncertainty A measure of the inherent variability of repeated measurements of a quantity.

which except for temporal resolution and spatial resolution of Default Styles are currently relegated to metadata in GML.

-- PaulDaisey - 16 Sep 2011

---

I'm trying to give some high-level comments from the viewpoint of the development and future maintenance of Technical Guidance documents for INSPIRE. Please note that further (more detailed) comments will hopefully become available after the completion of the consultation and testing exercise of INSPIRE Annex II+III data specifications, which will run until 21 October 2011.

I think the most important goal of the GML 4 revision should indeed be the modularisation of GML with the goal to make adoption and implementation by (INSPIRE) stakeholders easier. That said, care should be taken not to over-modularise the standard, i.e. to avoid replacing the current complexity with another one. If different modules evolve at different speeds (as suggested by some other commenters), care needs to be taken of the dependencies of the different modules. The management of such dependencies between specification (versions) has caused (and continues to cause) headaches in OGC in the past. Thus, the level of granulatity for the new GML modules (or profiles) should be considered well.

Another aspect for INSPIRE is overall stability of specifications, at least the core of the new version 4.0 should aim at being largely backwards-compatible with previous versions and implementations (or at least keep necessary updates to a minimum).

Finally, it has already become apparent in the Annex II+III developments that further work may be required in the following two areas:

• coverages
• ways of referrring to (possibly externally managed) code list values, terms from vocabularies, etc.

-- MichaelLutz (on behalf of the JRC INSPIRE data specifications team) - 19 Sep 2011

---

Sorry for this late input. I hope it is not too late!

My comment concerns the benefits to encode data capture rules as metadata elements in GML, especially in the context of INSPIRE. Future users of INSPIRE data will face the fact that spatial datasets produced on different countries/regions and following different data capture rules are rarely interoperable. The following image illustrates this well-known problem. It shows road network data (Euroregionalmap dataset) between Bulgaria (West part) and Romania (East part). The heterogeneity of the data is quite visible between the two countries. The computation of an accessibility indicator (for example) on such dataset will return meaningless outcomes, because the data capture rules are not homogeneous on both sides.

To solve this problem and make the data of both countries interoperable, there is a need to, first, document the data capture rules as metadata elements, and then transform the data to make as-if the 2 datasets had been produced following the same data capture rules (automatic transformation methods exist for that). Data capture rules should answer questions such as:

• Which entities are represented? Based on which criterion (size, characteristics, spatial context, etc.)?
• How the entities are identified as single entities?
• How to choose the class the entity should be represented in?
• How the spatial representation is built? With which LoD?
• …and maybe plenty other metaphysical questions data collectors often wonder.

GML (and ISO standards) already addresses many metadata elements, but data capture rules are missing. There is a need for a formal representation of these rules to encode them as metadata elements. Could it be addressed in GML4... or 5 :-)?

-- JulienGaffuri (member of the JRC INSPIRE data specifications team) - 20 Sep 2011

---

-- DavidBurggraf - 19 Sep 2011

Summary of comments:

Commenter	Linking	Modularization & Profile Support	Alternate encodings and compatibility areas to consider	Complexity	Tool Support	Extensions	Stability/backwards compatibility
Clemens Portele		Most significant proposal is likely the suggestion to break GML up into multiple namespaces. Consistent with OGC's Modular Specifications policy - aligns namespaces with specification modules. Would be both technical and social challenges with this approach Principal social challenge: too many namespaces can be bewildering. IMHO it is still worth it Should geometry be partitioned according to topological dimension (0, 1, 2, 3)? Or simple-geometries (points, lines, polygons) vs. more complex geometries (aggregates, solids, non-linear interpolation, etc)		trading one style of complexity for another can be a good thing if it has the right compensating benefits the 'complexity' of GML in either flavour is because it does a lot, and is not out of line with complexity in the other software systems that have large numbers of dependencies
Simon Cox	xlink never took off in any community other than GML, and after a slow start could replace @xlink:href with @rdf:resource and gml:identifier with @rdf:about	Determining the most useful boundaries for GML namespaces would indeed be a challenge Users could import the GMLcore and any additional modules they need. Should core correspond to the Simple Features profile? Very small components each living in a namespace would allow very flexible use One big problem: a lot of dependencies between components in different GML namespaces	RDF is the basis for many contemporary applications and architectures. GML applications could become immediately compatible with the semantic web with this one tweak. Atom (e.g. atom collection for feature collections)		very important we make sure that schema validation using a wide range of parsers is possible against a GML subset Wide parser support
Linda van den BrinK	supports idea of replacing xlink with rdf:resource	suggest to create a separate standard for the encoding of geometries that does not mention the word Feature it will be easier for RDF, etc to reuse geometry in GML	Should be clear positioning of GML and KML Should discuss further harmonization of GML and KML - having overlapping standards within OGC is confusing and should be avoided
Wilko Quak		agrees with modulatiry Need options to use simple subsets	Alternate encodings apart from XML like JSON JSON, RDF, Atom, GeoRSS?, GeoJSON?	in favour of almost anything that would make GML less complex and bulky should be possible to encode a Point in just a single element like <Point x=.. y=.. [srs=EPSG:N..] /> welcome any addition to GML to specifically denote axis-ordering	AJAX-based webapps the use of GML is painful
Just van den Broecke			harmonize observation and coverage modeling			advancement of coverages - discrete vs continuous, - harmonize with observation - support Multi*Coverages - refinement of CoverageFunction? - domain/range interleaved encoding - parametric CRS handling - ad-hoc combined CRSs GML SWG and WCS.SWG agreed to see the GML Application Schema for Coverages as a basis for further development
Peter Baumann		while GML3.x is pretty complete we really needed very little of it possible modularity with some well defined ‘profiles’ so you know what is supported	binary, JSON KML more useful in practice	More emphasis on usability/simplicity and less on complex data models – bear in mind what it is really being used for	More emphasis on usability Need better tool support, esp. client support (and complete, working support) most WFS clients (Arc or MapInfo? mostly) have pretty limited real support for GML and WFS Another issue was that styling was not possible. I can see the logic of separating presentation from content, but this is a tricky thing in practice (SLD is not supported widely at all in reality) Support for compressed XML is still not universal
Dan Cornford		very much in favour of modularization Standard profiles should be available that combine the modules necessary for a certain application domain It should be easy for a user to select the appropriate profile Modules should be created with an application domain in mind, i.e. the division into modules should be done based on usage situations There should at least be a simple features profile It is important to be able to validate against a 'profile' with standard XML parsers			Lack of software support. Many user's software could not import Top10NL (GML app schema) Little or no support for users of CAD systems ArcGIS had issues with multiple occurrences of attributes and multiple geometries Need conversion tools for GML to GIS and possibly Top10NL- GML to CAD
Robin Houtmeyers	Re the switch to RDF for XLinks, need to clearly evaluate the issues with XLinks and justify the switch to RDF From experience, many client and server apps do not support external references of any type. Internal links that use gml:id (e.g. href="#mygmlid") have been used successfully and we see no direct reason to change this AIXM 5 XLink guidance document w.r.t. abstract and direct links	Luciad is in favor of a more modular GML - biggest advantage would be that different modules can evolve at their own pace should allow for a very stable core part of GML that needs little updates Parts that are more evolving and/or still in a early phase (3D, temporality, coverages,...) can have their own modules, so they can go through a few iterations at a faster pace Candidates for the core of GML would include 2D geometries and the feature concept it could be interesting to introduce a lightweight core module that (for instance) matches with the Simple Features profile Related to the module split, it would be interesting to have a separate module for measures. the separation of measures seems feasible, because of the limited inter dependencies with the rest of the model		making it more easy for lightweight applications to support GML (or a part of it)		Need improvements for measures to enable applications schemas such as AIXM and WXXM to define their own measure types (next to the default ones in GML). The following improvements would be useful: 1. A dictionary system for unit of measures (UOMs) that can be extended with new ones; 2. The possibility to use non-numeric values such as Strings; for instance, AIXM 5 uses 'UNL' as value to represent an unlimited airspace height.	Core of GML4 should be very stable that needs little updates
Paul Daisey		Multiple namespaces (e.g. core, geometry, temporal, etc) might help comprehension, but at the very detailed level of granularity required to achieve the goal of creating a completely modular specification are liable to create a thicket of confusion specialized separate profiles can help with the tradeoff between simplicity and scope		A feature model in GML that has multi-valued properties or many-to-many associations is "too complex" for some GIS systems, even though join tables are a well known RDBMS design pattern Middleware tools/programming environments address the problem in general, but there are no well-documented GML-specific design patterns To enable development of such tools, create model-matching encoding rules between GML and other data encoding environments: - support for html 5 - between GML and JSON - binary support (limited bandwidth) GML4 should consider existing GML app schemas from large orgs and extensive user communities, in particular Time Space Position Information (TSPI)	Limitations of existing software environments must be augmented Middleware tools in particular programming environments (e.g. Hibernate for Java) address the problem in general, but there is very little well-documented GML-specific design patterns or tools GML Feature models with multi-valued properties or many-to-many associations is "too complex" for some GIS systems for Web applications, especially once support for HTML5 becomes widespread, model-matching encoding rules are needed between GML and JSON that go beyond what has already been achieved by GeoJSON	GML4 should consider existing GML app schemas from large orgs and extensive user communities, in particular Time Space Position Information (TSPI): - accuracy - precision - resolution - uncertainty except for temporal resolution and spatial resolution of Default Styles, the above are currently relegated to metadata in GML
Michael Lutz		most important goal for GML 4 should be modularisation of GML with the goal to make adoption and implementation by stakeholders (e.g. INSPIRE) easier care should be taken not to over-modularise the standard, i.e. to avoid replacing the current complexity with another one Re different modules evolve at different speeds, care needs to be taken about dependencies of different modules. Management of such dependencies between versions has caused (and continues) headaches in OGC in the past the level of granulatity for the new GML modules (or profiles) should be considered well				Enhance coverages	Another aspect for INSPIRE is overall stability of specifications at least the core of the new version 4.0 should aim at being largely backwards-compatible with previous versions and implementations

---