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

Is name or nameMap essential? #312

Closed
natalieesk opened this Issue May 6, 2016 · 17 comments

Comments

Projects
None yet
7 participants
@natalieesk

natalieesk commented May 6, 2016

Please Indicate One:

  • Editorial
  • Question
  • Feedback
  • Blocking Issue
  • Non-Blocking Issue

Please Describe the Issue:
We have implemented AS2 without a name or nameMap. We recently used the validator to try it out and received the following errors:

error / Object should have a 'name' or 'nameMap' property.
error /actor Object should have a 'name' or 'nameMap' property.

Is name really essential and not just a suggestion? Looking at https://www.w3.org/TR/activitystreams-vocabulary/#dfn-name we handle a human-readable name for type in our code. Is this something we need to change to be AS2 compliant?

@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell May 6, 2016

Collaborator

Providing a name (or what we called displayName in AS1) has been considered a best practice for quite some time given that not all implementation will understand all object types. The name gives the implementation a fallback to display even when it does not understand the type of object that it is working with.

Collaborator

jasnell commented May 6, 2016

Providing a name (or what we called displayName in AS1) has been considered a best practice for quite some time given that not all implementation will understand all object types. The name gives the implementation a fallback to display even when it does not understand the type of object that it is working with.

@natalieesk

This comment has been minimized.

Show comment
Hide comment
@natalieesk

natalieesk May 6, 2016

We have a concept of displayName for our Actor already. So we'll change
that to name then.

Thanks.

On 6 May 2016 at 17:45, James M Snell notifications@github.com wrote:

Providing a name (or what we called displayName in AS1) has been
considered a best practice for quite some time given that not all
implementation will understand all object types. The name gives the
implementation a fallback to display even when it does not understand the
type of object that it is working with.


You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#312 (comment)

Natalie Eskinazi__Consultant Software Developer
Emailneskinaz@thoughtworks.com
[image: ThoughtWorks] http://www.thoughtworks.com/

natalieesk commented May 6, 2016

We have a concept of displayName for our Actor already. So we'll change
that to name then.

Thanks.

On 6 May 2016 at 17:45, James M Snell notifications@github.com wrote:

Providing a name (or what we called displayName in AS1) has been
considered a best practice for quite some time given that not all
implementation will understand all object types. The name gives the
implementation a fallback to display even when it does not understand the
type of object that it is working with.


You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#312 (comment)

Natalie Eskinazi__Consultant Software Developer
Emailneskinaz@thoughtworks.com
[image: ThoughtWorks] http://www.thoughtworks.com/

@cwebber

This comment has been minimized.

Show comment
Hide comment
@cwebber

cwebber Sep 23, 2016

Contributor

So, I'm tempted to say we should reopen this. @rhiaro and I both have implementations where "name" or "nameMap" is not always supplied, for good reasons.

Contributor

cwebber commented Sep 23, 2016

So, I'm tempted to say we should reopen this. @rhiaro and I both have implementations where "name" or "nameMap" is not always supplied, for good reasons.

@rhiaro

This comment has been minimized.

Show comment
Hide comment
@rhiaro

rhiaro Sep 23, 2016

Member

+1 Chris

Chris and I just discussed today and we actually thought we'd resolved that name was not required. So did @tantek.

A friend of mine implementing AS2 the other day showed me a note with 'activity stream' as the name, which doooooesn't seem like something we should encourage, and does seem like something people are going to do to get through the validator..

Member

rhiaro commented Sep 23, 2016

+1 Chris

Chris and I just discussed today and we actually thought we'd resolved that name was not required. So did @tantek.

A friend of mine implementing AS2 the other day showed me a note with 'activity stream' as the name, which doooooesn't seem like something we should encourage, and does seem like something people are going to do to get through the validator..

@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Sep 23, 2016

Collaborator

The name has always been as SHOULD going back to AS1. If it's not something
specific it should be something generic related to the type. For instance,
"name": "note" would be acceptable. The idea is to give a human readable
fallback in case an impl does not understand a given type.

On Friday, September 23, 2016, Amy Guy notifications@github.com wrote:

+1

Chris and I just discussed today and we actually thought we'd resolved
that name was not required. So did @tantek https://github.com/tantek.

A friend of mine implementing AS2 the other day showed me a note with
'activity stream' as the name, which doooooesn't seem like something we
should encourage, and does seem like something people are going to do to
get through the validator..


You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
#312 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAa2eV_gE_WieVAYIv6AT1jkqFmCxti-ks5qs9QdgaJpZM4IYx4V
.

Collaborator

jasnell commented Sep 23, 2016

The name has always been as SHOULD going back to AS1. If it's not something
specific it should be something generic related to the type. For instance,
"name": "note" would be acceptable. The idea is to give a human readable
fallback in case an impl does not understand a given type.

On Friday, September 23, 2016, Amy Guy notifications@github.com wrote:

+1

Chris and I just discussed today and we actually thought we'd resolved
that name was not required. So did @tantek https://github.com/tantek.

A friend of mine implementing AS2 the other day showed me a note with
'activity stream' as the name, which doooooesn't seem like something we
should encourage, and does seem like something people are going to do to
get through the validator..


You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
#312 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAa2eV_gE_WieVAYIv6AT1jkqFmCxti-ks5qs9QdgaJpZM4IYx4V
.

@cwebber

This comment has been minimized.

Show comment
Hide comment
@cwebber

cwebber Sep 23, 2016

Contributor

@jasnell But any client can infer a "name": "note" as a crappy name if the name is of type Note anyway.

The difference is that when "name" is required, you can't tell that "name": "note" is something that's just a "well we HAVE to supply something, so..." or if it's actually useful. It might be that a UI is able to pick something to display that's better anyway, maybe selecting the first line of content or something.

But if "name": "Note" is supplied, the UI doesn't have that option. And again, it could have picked "Name" just as easily on its own anyway.

Contributor

cwebber commented Sep 23, 2016

@jasnell But any client can infer a "name": "note" as a crappy name if the name is of type Note anyway.

The difference is that when "name" is required, you can't tell that "name": "note" is something that's just a "well we HAVE to supply something, so..." or if it's actually useful. It might be that a UI is able to pick something to display that's better anyway, maybe selecting the first line of content or something.

But if "name": "Note" is supplied, the UI doesn't have that option. And again, it could have picked "Name" just as easily on its own anyway.

@tantek

This comment has been minimized.

Show comment
Hide comment
@tantek

tantek Sep 23, 2016

Collaborator

Re: "human readable fallback in case an impl does not understand a given type" this is a very bad idea and has unintended breaking consequences from experience in the IndieWeb community. The alternative we came up with was to make name totally optional, except for specific types (e.g. "article").

For "human readable fallback in case an impl does not understand a given type", we have found this to be a good use of "summary".

Collaborator

tantek commented Sep 23, 2016

Re: "human readable fallback in case an impl does not understand a given type" this is a very bad idea and has unintended breaking consequences from experience in the IndieWeb community. The alternative we came up with was to make name totally optional, except for specific types (e.g. "article").

For "human readable fallback in case an impl does not understand a given type", we have found this to be a good use of "summary".

@cwebber

This comment has been minimized.

Show comment
Hide comment
@cwebber

cwebber Sep 23, 2016

Contributor

I'm a-ok with MUST or SHOULD on Article, fyi.

Contributor

cwebber commented Sep 23, 2016

I'm a-ok with MUST or SHOULD on Article, fyi.

@cwebber

This comment has been minimized.

Show comment
Hide comment
@cwebber

cwebber Sep 23, 2016

Contributor

As I pointed out at the face to face, there's a possible i18n problem with requiring a name, because either you put english names everywhere, or you have to make every tiny like object into a 5kb nameMap that doesn't provide even necessarily all the translations your client could provide.

Also, as @evanp pointed out at the meeting, without a name, facebook might call something a like, something else might be a favorite, something might be a name or a tweet...

Contributor

cwebber commented Sep 23, 2016

As I pointed out at the face to face, there's a possible i18n problem with requiring a name, because either you put english names everywhere, or you have to make every tiny like object into a 5kb nameMap that doesn't provide even necessarily all the translations your client could provide.

Also, as @evanp pointed out at the meeting, without a name, facebook might call something a like, something else might be a favorite, something might be a name or a tweet...

@cwebber

This comment has been minimized.

Show comment
Hide comment
@cwebber

cwebber Sep 23, 2016

Contributor

From the face to face:

RESOLVED: Return distinction between "user entered or otherwise significant name" and "text fallback" and shift SHOULD from meaningful name to text fallback.

Note that the name for "textFallback" or whatever is not enforced by this resolution, it's up to the editors to choose a good (and maybe better) name.

Contributor

cwebber commented Sep 23, 2016

From the face to face:

RESOLVED: Return distinction between "user entered or otherwise significant name" and "text fallback" and shift SHOULD from meaningful name to text fallback.

Note that the name for "textFallback" or whatever is not enforced by this resolution, it's up to the editors to choose a good (and maybe better) name.

@cwebber

This comment has been minimized.

Show comment
Hide comment
@cwebber

cwebber Sep 23, 2016

Contributor

Also could this be re-opened until that's completed? :)

Contributor

cwebber commented Sep 23, 2016

Also could this be re-opened until that's completed? :)

@cwebber

This comment has been minimized.

Show comment
Hide comment
@cwebber

cwebber Sep 23, 2016

Contributor

btw, personal opinion, textFallback is no good, but fallbackText: so good!

Contributor

cwebber commented Sep 23, 2016

btw, personal opinion, textFallback is no good, but fallbackText: so good!

@evanp evanp reopened this Sep 23, 2016

@evanp

This comment has been minimized.

Show comment
Hide comment
@evanp

evanp Sep 23, 2016

Collaborator

Reopened based on discussion

Collaborator

evanp commented Sep 23, 2016

Reopened based on discussion

@BigBlueHat

This comment has been minimized.

Show comment
Hide comment
@BigBlueHat

BigBlueHat Sep 23, 2016

Member

@evanp currently the validator throws an Error when name is missing (rather than a Warning)--which (given the description by @natalieesk) is quite possibly the genesis of this issue:
https://github.com/w3c-social/activitystreams-validator/blob/master/lib/validator.js#L168

Member

BigBlueHat commented Sep 23, 2016

@evanp currently the validator throws an Error when name is missing (rather than a Warning)--which (given the description by @natalieesk) is quite possibly the genesis of this issue:
https://github.com/w3c-social/activitystreams-validator/blob/master/lib/validator.js#L168

@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Sep 23, 2016

Collaborator

I strongly recommend a name like as:label _iff_ a new field is being considered.
Otherwise, bring back the as:title property or document a convention for the use of as:summary.

Collaborator

jasnell commented Sep 23, 2016

I strongly recommend a name like as:label _iff_ a new field is being considered.
Otherwise, bring back the as:title property or document a convention for the use of as:summary.

@rhiaro

This comment has been minimized.

Show comment
Hide comment
@rhiaro

rhiaro Sep 23, 2016

Member

+1 fallbackText or fallbackName as the most semantically clear option for the required field. To me it says this is a backup, which may be replaced by a consumer, but has to be there in case the consumer doesn't know anything more sensible to do with it and is deferring to the publisher.

And keeping use of name the same (human-readable, significant, meaningful) but removing the SHOULD.

Member

rhiaro commented Sep 23, 2016

+1 fallbackText or fallbackName as the most semantically clear option for the required field. To me it says this is a backup, which may be replaced by a consumer, but has to be there in case the consumer doesn't know anything more sensible to do with it and is deferring to the publisher.

And keeping use of name the same (human-readable, significant, meaningful) but removing the SHOULD.

@evanp

This comment has been minimized.

Show comment
Hide comment
@evanp

evanp Nov 18, 2016

Collaborator

We resolved on 2016-11-08 as follows: "change name to may, if no name, SHOULD provide a plaintext summary, add a section on string representation, add guidance to the fact that summary or name may be too long"

https://www.w3.org/wiki/Socialwg/2016-11-08-minutes

Collaborator

evanp commented Nov 18, 2016

We resolved on 2016-11-08 as follows: "change name to may, if no name, SHOULD provide a plaintext summary, add a section on string representation, add guidance to the fact that summary or name may be too long"

https://www.w3.org/wiki/Socialwg/2016-11-08-minutes

@evanp evanp closed this in 74cb846 Nov 18, 2016

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