<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7651.59">
<TITLE>RE: [GeoJSON] Point as list of one point, or list of coords</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>> Having batted this around on IRC, I think what we can do is this<BR>
><BR>
> (a) any consumer or producer is free to implement any subset of the spec<BR>
<BR>
How would an all-powerful consumer request the Complete profile, and vice-versa? We are in danger of creeping into interface definitions, instead of object notation.<BR>
<BR>
> (c) we define at least two "packages" of conformance:<BR>
<BR>
There is some discussion in the OGC Architecture Board about metamodels for specs, specifically core+extensions versus base+profiles. The former defines the minimum content, and extensions build on it. The latter attempts to describe the entire problem/world, and then restricts it (think GML and GML simple feature profile).<BR>
<BR>
I would like to see GeoJSON as a core+extensions, rather than a base+profiles. How about RFC-001 becoming just Points, then adding LineString, Polygon (with holes, I think) and Box as RFC-002, then multis (all flavours) as RFC-003, then multiple geometries per feature as RFC-004, then... you get the picture.<BR>
<BR>
(GeoRSS is different here, with two separate geometry encodings that are largely unrelated.)<BR>
<BR>
That still leaves the "how does a consumer request some specific subset?" question open, of course. There is also the problem of a consumer detecting what it has in its hand from a producer. GML etc. have the "advantage" of XML Schema and namespaces, but JSON doesn't. I don't have an answer for that either.<BR>
<BR>
M</FONT>
</P>
</BODY>
</HTML>