Proposed - Allow for the h-geo properties to be added to an h-entry

[dshanske]

This encompasses the proposed properties for h-entry of p-latitude and p-longitude, and probably covers p-altitude on this basis even though this was not proposed.

The reason for allowing these, as opposed to p-location as an embedded h-geo, would be in cases where nested microformats are not preferable, and a simplified structure preferred.

So, these would represent the location of the h-entry in coordinates, which could alternatively be represented as a nested p-location. In this case, a p-location could still be present representing a textual version of a location name.

[dshanske]

Related indieweb/microsub#45

[sknebel]

would be in cases where nested microformats are not preferable, and a simplified structure preferred.

What are those cases?

[dshanske]

For one, Micropub and Microsub, which use simplified mf2 vocabulary.

[sknebel]

I don't see where microsub has an issue with nested formats? For micropub, I personally don't think adding more variants and special cases to mf2 just to extend support for the form-encoded variant is positive for effort overall, and the JSON form again does not have problems with nested formats.

[dshanske]

@sknebel Microsub tries to go for a simplified representation. But, point taken there.

Added this based on these properties being on the proposed list. Will leave this open for commentary. Maybe the solution is the proposal is rejected.

[sknebel]

sure, not complaining that you made the issue - to the contrary, thanks for doing the bookkeeping :)

Maybe to phrase my objection more generally: My concern is that this adds another variation of how things can be marked up, that most consumers will normalize in some fashion anyways (e.g. to generate jf2, or post markup, or ...) and that then all consumers need to handle, while I don't see a real benefit for publishers over the existing markup for location - it doesn't add anything we can't already express.