[Geopackage] Moving towards 1.0.2 (or whatever)

Jeff Yutzler jeffy at imagemattersllc.com
Wed Dec 30 09:44:32 EST 2015


Brad,


> I think it would be more reasonable to  finish the spec, then give a
> reasonable
> (30 day) review period on that spec. I'm not part of the OGC though, so
> whatever works for you.


Well, we did think we were done. The fixes for #132/137 were merged a month
ago and as of the end of the Dec 15 SWG we had no open technical issues.
Keep in mind that in the traditional OGC process, the spec isn't even
viewable by the public until the request-for-comment stage. We've been
operating publicly for a while but it wasn't until I posted the release
notes that I started getting feedback on the recent changes. If OGC makes
an official announcement of a review period, we will hopefully get more
feedback. The sooner the better.

That won't be true for the change in #132 if the  provider implemented
> extensions, because the description is now incorrect. Its a SHALL, so
> consumers could be relying on it, even if you don't know who they are.


If someone is keying on the description text in the gpkg_extensions table,
they are doing it wrong. It was never the intent to use the description to
perform a lookup. That's what the extension_name is for. This is confirmed
by the abstract test suite for each individual extension. Perhaps this
never should have been an enumerated requirement, but making it a SHALL
statement is appropriate because if an extended GeoPackage shows up
somewhere, we want a human to be able to figure out where the extensions
are documented.

I think your change notes should reflect that, and perhaps be suggesting
> 1.1.0,
> not 1.0.2.


I don't believe we're at a point where this needs to be called 1.1.0 but
we'll see what others have to say, especially once we re-resolve 137.

-Jeff

On Tue, Dec 29, 2015 at 12:00 PM, <
geopackage-request at lists.opengeospatial.org> wrote:

> Date: Tue, 29 Dec 2015 10:47:28 +1100
> From: Brad Hards <bradh at frogmouth.net>
> To: geopackage at lists.opengeospatial.org
> Subject: Re: [Geopackage] Geopackage Digest, Vol 18, Issue 4
> Message-ID: <30239415.cWZFuBx86P at saxicola>
> Content-Type: text/plain; charset="us-ascii"
>
> On Sun, 27 Dec 2015 11:02:28 PM Jeff Yutzler wrote:
> > Brad,
> > I don't think I understand what you are getting at regarding #132.
> Perhaps
> > the issue is that I never got around to updating Requirement 2 to bump
> the
> > version number. (I just added that as issue 188 / pull request 189.) A
> > 1.0/1.0.1 implementation would have extension names as annexes and a
> 1.0.2
> > implementation would have them as sub-annexes. We haven't been rigorous
> > about avoiding SHALL statements outside of enumerated requirements.
> > Addressing this could get complicated and could easily do more harm than
> > good.
> I think of patch level releases (x.y.z -> x.y.z+1) as "if the
> implementation
> was compliant before, it won't be non-compliant now". Alternatively, the
> consumer can rely on a conforming producer to make stuff that doesn't
> break a
> conforming consumer.
>
> That won't be true for the change in #132 if the  provider implemented
> extensions, because the description is now incorrect. Its a SHALL, so
> consumers could be relying on it, even if you don't know who they are.
>
> I think your change notes should reflect that, and perhaps be suggesting
> 1.1.0,
> not 1.0.2.
>
> > I haven't heard specifically, but I assume there will be a 30 day review
> > period or something like that before 1.0.2 can go up for adoption vote. I
> > am just trying to get that clock started. We are still able to fix issues
> > after that.
> I think it would be more reasonable to  finish the spec, then give a
> reasonable
> (30 day) review period on that spec. I'm not part of the OGC though, so
> whatever works for you.
>
> Brad
>
>

-- 
Jeff Yutzler
Image Matters LLC <http://www.imagemattersllc.com/>
Mobile: (703) 981-8753
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geopackage/attachments/20151230/f2d68ab3/attachment.html>


More information about the Geopackage mailing list