It doesn’t return the Microformats JSON, it converts it to its jf2 format first.
It might be worth opening an issue on jf2 to see if they want to keep an explicit name
property. Their “author” syntax says it “consists of a name” and more, but that’s not marked as a MUST. For a jf2feed on the other hand name
is a SHOULD.
The real question is, do you see any reasons for postponing this change because of your use of a mf2 parser as a service? I think not?
Documenting from yesterday’s chat, because nobody could remember this and I can’t find it elsewhere:
So I think the (as of now) latest proposed spec change would be:
p-name
MUST NOT be implied if there are any explicit p-*
or e-*
properties, or any nested microformats.Currently all mf2 items have a name property, because of implied name. If we change this, some code using the parsers could fail if it assumes a name is present.
Here too I will just document an answer given in chat, this time by @aaronpk:
may just mean it has to be released as a major version number [of the parsers]
Assuming something like semver is being used, any major version bump should signify possible API changes to the user. I too don’t think that would be an issue.
There might be an issue if someone is using parsers-as-a-service, e.g. always getting their mf2 parser output from php.microformats.io
. But I don’t think anyone ever advertised their online parsers as a service?
No, that's not what I meant.
Only the order of the channel IDs specified will be changed
In your example 1, c
has moved as well, even though only d
and b
were given.
To move a channel up or down...
This is equivalent to swapping two adjacent items.
I didn't give an example of setting the order of three items because I couldn't think of a UI where it would make sense, but it is still possible.
The nice thing about this approach is that the same update logic works for all the use cases, and doesn't matter how many items are in the list, and is atomic.