advance h-event to Microformats Specification

[tantek]

h-event is currently a Microformats Draft Specification. As part of issue #1, we should determine if (and how) h-event is ready to become a Microformats Specification and thus subject to more explicit change control.

Per the process: http://microformats.org/wiki/process#Specifications

There are a number of preconditions to be satisfied. Anyone can help document if (and how) those preconditions are satisfied and we can use this issue to track that.

[tantek]

Preconditions for Microformats Specification satisfied per:

• all outstanding technical **-issues resolved (hit zero issues for a few weeks) (much longer than that), both issues are here are meta
• 8 sites / publishing implementations https://indieweb.org/event#IndieWeb_Examples
• 4 consuming implementations https://indieweb.org/event#Consuming_Tools_And_Services, 3 of which are end user tools (1 library).

So we're ready to go! Going to announce and give folks a quick chance to give feedback before flipping the template switch. (if any subsequent objections, we can evaluate and revert to draft as needed while evaluating)

[Zegnat]

Does it become significantly harder to change properties after “flipping the switch”? If so (I am not fledged in the Microformats processes) we might need to do some changes to h-event first.

The current draft specification does not adress using h-event as a root object of h-feed, the way IndieWeb has been pushing it. This (newer?) usage has brought in some minor differences that are worth documenting. To put h-event on par with h-entry properties such as uid, syndication, published, updated have been pulled over.

Just 2 examples taken from IndieWeb implementations. Bolded properties are those currently documented for h-event, others are taken over from h-entry:

1. Ben Werdmüller, https://werd.io/2017/homebrew-website-club-june-14-2017
   • author
   • comment
   • name
   • summary
   • location
   • url
   • published
   • start
   • end
   • content
2. Kyle Mahan, https://kylewm.com/2014/12/homebrew-website-club-17-december-2014
   • author
   • location
   • like
   • comment
   • name
   • url
   • uid
   • shortlink
   • syndication
   • start
   • end
   • published
   • content

One difference between h-event and h-entry that sometimes trips people up is description (h-event) vs content (h-entry). Both the above IndieWeb examples use the content property, an entry-ism. (This was discussed on the IndieWeb IRC ~1 week ago, my reply to KartikPrabhu and KevinMarks back then.)

[tantek]

Does it become significantly harder to change properties after “flipping the switch”? If so we might need to do some changes to h-event first.

In some ways yes, though in some way it becomes more clear how to add properties once we flip the switch with the explicit change control process (see issue #1 ) - in particular with putting properties in various states / lists as they are in h-entry and advancing them according to evidence of uptake and interop.

Looks like all the example published properties you showed above are about adding properties, with the one exception of "description", so that process should work fine for that.

I think it makes sense to keep "description" as is for event because that's all it is. Unless something is a virtual online only event, its content is the physical real world event itself, not something online.

As far as adding "content" (which I think is what you're asking for), it may need some tweaking in terms of what does a "content" property mean on an event (probably means something similar to description most of the time, but could or should it mean something different otherwise? etc.)

Either way that's worthy of its own discussion. The summary is still the same, a "Microformats Specification" h-event can still get new properties added per the proposed/draft/core distinction as documented (and has been successfully) in h-entry.

[kevinmarks]

The name/summary/content split has been working well in multiple microformats - description has historically been ambiguous between summary and content. Is the distinction that the description is beforehand and the summary/content is after it takes place?

…

On 16 Jun 2017 2:47 am, "Tantek Çelik" ***@***.***> wrote: Does it become significantly harder to change properties after “flipping the switch”? If so we might need to do some changes to h-event first. In some ways yes, though in some way it becomes more clear how to *add* properties once we flip the switch with the explicit change control process (see issue #1 <#1> ) - in particular with putting properties in various states / lists as they are in h-entry and advancing them according to evidence of uptake and interop. Looks like all the example published properties you showed above are about *adding* properties, with the one exception of "description", so that process should work fine for that. I think it makes sense to keep "description" as is for event because that's all it is. Unless something is a virtual online only event, it's content is the physical real world event itself, not something online. As far as adding "content" (which I think is what you're asking for), it may need some tweaking in terms of what does a "content" property mean on an event (probably means something similar to description most of the time, but could or should it mean something different otherwise? etc.) Either way that's worthy of its own discussion. The summary is still the same, a "Microformats Specification" h-event can still get new properties added per the proposed/draft/core distinction as documented (and has been successfully) in h-entry. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGCwBPxcMuGH_VC0FlxBr-72q1vsXtsks5sEdn-gaJpZM4MN012> .

[tantek]

The name/summary/content split has been working well in multiple microformats - description has historically been ambiguous between summary and content.

This is an interesting assertion. Do you know if any of the aforementioned[1] h-event consuming tools/services parse for content in particular? Or only description? Or both (e.g. one falling back to the other)?

Also, we'd need to do more analysis of existing real world h-event publishing examples to see if any (how many) depend on "description" being consumed (i.e. lack a separate "content" property) to see if w need to specify backcompat treatment of mf2 "description" in the context of h-event.

@kevinmarks if that was your intent (find a way to drop or deprecate "description") could you file a new issue for that in particular so we can start debating that separately from the spec advancement issue?

[1] https://indieweb.org/event#Consuming_Tools_And_Services