<div dir="ltr">Thanks for getting back to me. Opened up a pull request. So you'd suggest something more along the line of <div style>    <span style="color:rgb(80,0,80)">A feature collection object MAY have a member with any other name besides type,features,[other reserved words to be added]. The </span></div>
<div style="color:rgb(80,0,80)">    value of the member is an object (any JSON object or a</div><div style="color:rgb(80,0,80)">    JSON null value).</div><div><br><br><div class="gmail_quote">---------- Forwarded message ----------<br>
From: <b class="gmail_sendername">Sean Gillies</b> <span dir="ltr"><<a href="mailto:sean.gillies@gmail.com">sean.gillies@gmail.com</a>></span><br>Date: Fri, May 17, 2013 at 4:46 PM<br>Subject: Re: [GeoJSON] properties on FeatureCollection objects.<br>
To: Calvin Metcalf <<a href="mailto:calvin.metcalf@gmail.com">calvin.metcalf@gmail.com</a>><br><br><br><div dir="ltr"><div><div><div>Calvin,<br><br></div>It's okay to send pull requests for middle.mkd alone. We'll run the pandoc/rfc2xml scripts.<br>
<br></div>More generally, maybe we just need to add a reminder that the must-ignore rule applies to JSON: processors must ignore objects (like a FeatureCollection properties or schema) that they don't understand. This makes JSON easy to extend. You can add objects freely to your GeoJSON and unless they collide with the objects we're specifying in the GeoJSON profile, you can't trouble anybody.<br>

<br></div>Later, if FeatureCollection properties turn out to be a great idea and catch on, they might become part of a new profile.<br></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div class="h5">
On Fri, May 17, 2013 at 6:29 AM, Calvin Metcalf <span dir="ltr"><<a href="mailto:calvin.metcalf@gmail.com" target="_blank">calvin.metcalf@gmail.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div class="h5"><div dir="ltr">It might make sense to clarify whether a properties object can be in a feature collection, currently since you can have any extra values in there you can put a properties object there. Instead I'd suggest a adding a paragraph to the feature collection def which says<div>


<br></div><div><div>    A feature collection object MAY have a member with the name "properties". The </div><div>    value of the properties member is an object (any JSON object or a</div><div>    JSON null value).</div>


<div><br></div><div>yes technically redundant but on the other hand there quite a few questions on stack exchange asking just this, plus depending on how the CRS discution goes, feature collection level properties might be the most sense to communication information about the data in the feature collection.</div>


<div><br></div><div>I can submit a pull request once I get to a computer that has haskel installed on it.</div><span><font color="#888888">-- <br>-Calvin W. Metcalf
</font></span></div></div>
<br></div></div>_______________________________________________<br>
GeoJSON mailing list<br>
<a href="mailto:GeoJSON@lists.geojson.org" target="_blank">GeoJSON@lists.geojson.org</a><br>
<a href="http://lists.geojson.org/listinfo.cgi/geojson-geojson.org" target="_blank">http://lists.geojson.org/listinfo.cgi/geojson-geojson.org</a><br>
<br></blockquote></div><span class=""><font color="#888888"><br><br clear="all"><br>-- <br>Sean Gillies
</font></span></div>
</div><br><br clear="all"><div><br></div>-- <br>-Calvin W. Metcalf
</div></div>