Skip to content
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

Mention this is JSON-specific #13

Closed
dret opened this issue Jul 28, 2016 · 16 comments
Closed

Mention this is JSON-specific #13

dret opened this issue Jul 28, 2016 · 16 comments

Comments

@dret
Copy link

dret commented Jul 28, 2016

it should be mentioned early and clearly (abstract and intro) that this is only about type sniffing in JSON data. it seems that people are confused because this isn't mentioned clearly. if people agree i'll happily submit a PR.

@tantek
Copy link
Owner

tantek commented Jul 28, 2016

It's a bit early for such editorial details, and there's no need to assume particular syntax since the algorithm itself is semantic, independent of syntax.

it seems that people are confused

Citations please?

@aaronpk
Copy link
Collaborator

aaronpk commented Jul 28, 2016

This spec can be used when interpreting a Micropub form-encoded request, so this is actually not JSON-specific.

@dret
Copy link
Author

dret commented Jul 28, 2016

On 2016-07-28 16:00, Tantek Çelik wrote:

It's a bit early for such editorial details, and there's no need to
assume particular syntax since the algorithm itself is semantic,
independent of syntax.

is it?
https://www.w3.org/TR/2016/WD-post-type-discovery-20160728/#algorithm
tries to make it sound like this a little bit, but i am wondering what
syntax (or model) other than JSON fits that language.

it seems that people are confused

Citations please?

https://twitter.com/asbjornu/status/758791425521774592

@tantek
Copy link
Owner

tantek commented Jul 28, 2016

Wow that Twitter thread started by @dret https://twitter.com/dret/status/758692512743628804 which starts by mocking this draft (unsolicited AFAIK) “and there you were thinking the days of "MIME type sniffing" are over” and then further mischaracterizes the draft “something you'd usually do via media types or document models”.

There's definitely confusion in that Twitter thread, yet I see very little of it in good faith, quite the opposite, it seems to be mostly Twitter-sniping.

When it was noted "I don’t understand the use case", @dret makes up an answer instead of citing the spec which has a whole section on "use cases:" https://www.w3.org/TR/2016/WD-post-type-discovery-20160728/#usecases

It's that made-up answer by @dret that caused the confusion in the cited tweet https://twitter.com/asbjornu/status/758791425521774592, not the spec, thus I'm going to close this issue.

If there are specific questions about the spec from implementers that are not answered directly by sections named as such in the spec, please file a specific issue for each such question, and I can add them to an FAQ or add normative text as needed.

@tantek tantek closed this as completed Jul 28, 2016
@melvincarvalho
Copy link

melvincarvalho commented Jul 28, 2016

I think this issue was closed prematurely. I would also like to note this as patterned behavior from @tantek.

The original post makes what I think is a reasonable point about having a well defined document model, which is how other W3C specs work. Indeed I think on one telecon it was mentioned that this may be trying to reinvent inferencing.

Duplication of effort may be a concern here.

@dissolve
Copy link

Its pretty clearly not JSON specific. Any confusion would be to another point, has nothing to do with documenting it as JSON specific.

@melvincarvalho
Copy link

@dissolve

e.g. Activity Streams (1.0 or 2.0) JSON, or JSON output from [ microformats2-parsing]

JSON is the only thing mentioned in the examples. Perhaps this is the cause of confusion.

@dissolve
Copy link

@melvincarvalho html + mf2 is the example and then AS2 is used for output. Thats 1 serialization its applying to and a different serialization for output.

Perhaps then it would be worth making a short mention that this can apply to any post data structure. serialization is irrelevant.

@tantek tantek reopened this Jul 29, 2016
@melvincarvalho
Copy link

@dissolve thanks for the clarification. That makes sense.

@tantek
Copy link
Owner

tantek commented Jul 29, 2016

@dissolve wrote:

Perhaps then it would be worth making a short mention that this can apply to any post data structure. serialization is irrelevant.

This is a constructive suggestion, I'll make an edit accordingly.

@melvincarvalho wrote:

I would also like to note this as patterned behavior from @tantek.

This is a false unsubstantiated accusation made in bad faith. I've not closed any issues like that. Please stop with such accusations as they are counter to W3C PWE and will be reported as such.

In general I prefer to close issues where either there is nothing actionable remaining, or editorial suggestions made in bad faith (such as starting a twitter thread with a mocking comment, then filing an issue because of it). No need to let unuseful issues linger.

As shown above, when new and constructive suggestions are made, I am more than happy to re-open an issue accordingly.

@melvincarvalho
Copy link

melvincarvalho commented Jul 29, 2016

Issues should only be closed with apparent consensus of the participants. If consensus cannot be reached, it is elevated to a WG telecon, and then closed with consensus of the Working Group.

https://www.w3.org/wiki/Socialwg/Github_Process

Only a few minutes passed before your response and closing the issue. IMHO that could not have been enough time to allow consensus of the participants to be reached.

In any case, thanks for reopening. And allowing constructive suggestions.

@melvincarvalho
Copy link

This is a false unsubstantiated accusation made in bad faith.

Is that really accurate? Someone removed me from the admin group of the w3c github repo without explanation and without recourse. Was it you? I can go over a number of issues there were closed prematurely. But is it a good use of time?

I've not closed any issues like that.

I am willing to debate the contrary position.

Please stop with such accusations as they are counter to W3C PWE and will be reported as such.

You are in a leadership position in this group and this kind of response is what I consider as confrontational and IMHO is the style of response that has potential to be viewed negatively. My strong desire is not to escalate, but if you wish to do so, I will be compelled to defend myself. I plead with you that both our time could be better spent taking the social web forward.

@tantek let me say that when I met you at TPAC you were a wonderful and inspirational figure. You encouraged me to join indieweb and try to make the social web a better place.

Interaction in a remote context has been, understandably, been less than optimal. We are all trying to fight the good fight, and we've not been doing that.

Let's all take a deep breath and realize we're on the same side and try to do things better ...

@dissolve
Copy link

dissolve commented Aug 5, 2016

Just to talk to your question of who removed you as an admin from the group. That was me.
This was an unofficial github group, and not github.com/w3c (to be clear to anyone reading this later.)

That was done after someone added Henry as an admin to the group, well after he rage-quit the working group. At the time you were one of the few admins and quoting him quite often. Was that you that added him?

I mentioned this to Tantek and told him I was removing henry from the group entirely (as having him as admin was completely inappropriate) and I removed anyone else who was not an editor (there were only a few) and finally removed myself as well (as I was not an editor at the time either).

The meeting after this (which I believe was the F2F) this was brought up and we resolved on some new standards for using github.

A better question is also why were you so bothered by losing admin to that group? The only things it would get you were the ability to add people to the group (which should be controlled by chairs), the ability to delete comments (which you really should never be doing) and the ability to re-open issues against a chair or editor's decision to close them (which you should also not do). There is a time and place for those, its on the telcons. And you had a recourse for losing admin, again, telcons.

That said, I would point out that in the past, I do remember you complaining that issues were closed quickly. However, I believe any examples you might come up with were prior to the decision on how to handle github. This issue, however was about editorial changes that the editor rejected after it seems to have been made in bad faith. If a thread goes off topic, that should be another issue, closing it has nothing to do with that.

@melvincarvalho
Copy link

@dissolve thanks for clarifying and the explanation, I honestly didnt know who removed me, I did ask but no one told me until now, which was an unedifying experience. This problem was that one issue was not only closed, but also locked. Therefore people that wanted to comment were not able to. Only admins can lock. So I wanted to keep the issue open for say a 24 hour period so that new issues could be extracted. This was prior to the rules at the F2F. As you say, it was an unofficial github group, so to be locked out without explanation was frustrating. Thank you for clearing up the matter.

tantek added a commit that referenced this issue Nov 22, 2016
explicitly note h-entry as another example lacking explicit post type, and note discovery applies independent of serialization to resolve issue #13
@tantek
Copy link
Owner

tantek commented Nov 22, 2016

@dret, per @dissolve's suggestion above, I've noted explicitly in the intro "Post type discovery can apply to any post data structure independent of serialization". If that clarification is good enough for you, go ahead and close this issue.

...

Upon re-reading all the comments, in summary @melvincarvalho, your initial complaint "I would also like to note ..." had nothing to do with the details of this specific issue (your complaint was "meta" as it were) and I should have pointed that out as off-topic and inappropriate here to start with. So I'm noting that now, for the record, and requesting that in the future you refrain from off-topic tangents in github spec issues, and instead, file them where appropriate instead. If you're not sure where the appropriate place is, ask for help directly from any of the working group chairs or in #social IRC on irc.w3.org. Thanks!

@tantek
Copy link
Owner

tantek commented Mar 1, 2017

https://www.w3.org/wiki/Socialwg/2017-02-28-minutes#resolution04 : Social Web WG resolved to close this issue as resolved since text has been added to the document, now published as an updated working draft: https://www.w3.org/TR/2017/WD-post-type-discovery-20170301/

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

No branches or pull requests

5 participants