Subject: Re: [Geojson] Extensibility of GeoJSON

From: Jeff Yutzler <[email-masked]>
Date: Wed, 25 Nov 2015 15:12:31 -0500

Allan,
See inline.

---------- Forwarded message ----------
> From: Allan Doyle <[email-masked]>
>
> * Feature properties are presented in tabular form.
>
>
> Please explain what this means.
>
> My wording was imprecise. Feature properties are presented in key/value
form with the values as String literals. The point is that GitHub and most
other JavaScript-based clients will render complex properties with
something unusable like "[object Object]".

> How, specifically, would a defined mechanism solve the problem? (This is
> asked in total innocence, not to be obstructive. I really want to
> understand the answer.)
>

Anything put into `properties` has by definition no semantic meaning. An
extension mechanism would inform producers how to provide information with
a semantic meaning (which logically should not go into `properties`). The
mechanism would also inform the client "hey, I'm including something with a
specific semantic here, in case you're interested."

This would virtually eliminate key conflicts. The only time you would have
a conflict is that if two people named different extensions the same thing
and used the same keys for encoding the data in the extension. This should
not happen where in the status quo key conflicts are inevitable.

-Jeff

---

From: Allan Doyle <[email-masked]>
Date: Wed, 25 Nov 2015 15:44:07 -0500

Thanks, Jeff.

> On Nov 25, 2015, at 3:12 PM, Jeff Yutzler <[email-masked]> wrote:
> 
> Allan,
> See inline.
> 
> From: Allan Doyle <[email-masked] <mailto:[email-masked]>>
> My wording was imprecise. Feature properties are presented in key/value form with the values as String literals. The point is that GitHub and most other JavaScript-based clients will render complex properties with something unusable like "[object Object]”.

This helps. I’d be happier with a warning that this can happen than I am with the processing model stuff. I’m not in favor of precluding it.
>  
> How, specifically, would a defined mechanism solve the problem? (This is asked in total innocence, not to be obstructive. I really want to understand the answer.)
>  
> Anything put into `properties` has by definition no semantic meaning.

The semantic meaning of ‘properties’ is actually undefined.

> An extension mechanism would inform producers how to provide information with a semantic meaning (which logically should not go into `properties`). The mechanism would also inform the client "hey, I'm including something with a specific semantic here, in case you're interested.” 

Not sure why that’s logical. But ok.

> 
> This would virtually eliminate key conflicts. The only time you would have a conflict is that if two people named different extensions the same thing and used the same keys for encoding the data in the extension. This should not happen where in the status quo key conflicts are inevitable.

I’m not convinced that any of those 3 sentences are true. 

I think I’d be ok with guiding people to the use of properties since it’s clearly there for a reason and that reason is not really spelled out. I think it would make sense to actually put a sentence about this into 2.2, bullet 2.

I still need to be convinced that there will be a meltdown if the spec remains essentially neutral on the topic of extensions.

	Allan