New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

advance h-event to Microformats Specification #2

Open
tantek opened this Issue Feb 28, 2017 · 5 comments

Comments

Projects
None yet
3 participants
@tantek
Member

tantek commented Feb 28, 2017

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

This comment has been minimized.

Show comment
Hide comment
@tantek

tantek Jun 15, 2017

Member

Preconditions for Microformats Specification satisfied per:

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)

Member

tantek commented Jun 15, 2017

Preconditions for Microformats Specification satisfied per:

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

This comment has been minimized.

Show comment
Hide comment
@Zegnat

Zegnat Jun 15, 2017

Member

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.)

Member

Zegnat commented Jun 15, 2017

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

This comment has been minimized.

Show comment
Hide comment
@tantek

tantek Jun 16, 2017

Member

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.

Member

tantek commented Jun 16, 2017

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

This comment has been minimized.

Show comment
Hide comment
@kevinmarks

kevinmarks Jun 16, 2017

Member
Member

kevinmarks commented Jun 16, 2017

@tantek

This comment has been minimized.

Show comment
Hide comment
@tantek

tantek Jun 16, 2017

Member

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

Member

tantek commented Jun 16, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment