5 ms·

So... you're saying it should have been conceived of as a particular file type and attached, like all other non-message-related elements? Would Google encode a

by roc 13y ago

So... you're saying it should have been conceived of as a particular file type and attached, like all other non-message-related elements? Would Google encode a vcf file in JSON and embed it in the message? How is handling VCF different than handling other optionally-actionable data?

dragonwriter 13y ago
> So... you're saying it should have been conceived of as a particular file type and attached, like all other non-message-related elements? No, if I was saying that, you would have seen those words in my message rather than yours. If you want to say that, go ahead, but don't misattribute it to me. But if you were to make that argument, I'd probably point out that its not "non-message-related" (actually, the biggest problem I have with it -- at least with the examples -- is that rather than adding semantic markup to the main content its all done by adding largely-redundant markup to the <head> element of the main content; I'm not sure if this is required, though, and I would hope it isn't since schema.org microdata doesn't normally require this mechanism, and this style is an uncomfortable hybrid between separate attachments than embedded semantic context.) And the file type is HTML. I don't see why an additional filetype is needed for this. > Would Google encode a vcf file in JSON and embed it in the message? I would be very much unsurprised if Google expanded its schemas-in-email support to include the schema.org Person type [1] and related types needed to support it, which provide the functionality provided by vCard (and a lot more). Since, after all, Google already supports that schema type for rich snippets in search. [1] http://www.schema.org/Person http://www.schema.org/Person > How is handling VCF different than handling other optionally-actionable data? vCard was a solution that was well adapted to the state of internet communications in 1995, but not necessarily the best model for new functionality in 2013.
- roc 13y ago
  > "No, if I was saying that, you would have seen those words in my message rather than yours." No-one was 'misattributing' anything to anyone. It was a figure of speech. Welcome to the sarchasm my friend. > "its not "non-message-related"" A bad word choice on my part. it is indeed message related; I was just (poorly) trying to draw a line between the message itself and the potentionally-actionable addenda. This whole project seems like an unnecessary marriage of the two. > "I don't see why an additional filetype is needed for this." For the same reason we have vcf even though it just happens to be particularly-formatted text. The filetype is more than the encoding. It's a hint to the client and the operating system as to how something should be handled. And should a given client not be aware of these 'actions', using a file-type enables the host system to present an application or extension that is. Again, not unlike VCF. "Aware" clients could process and present these 'actions' alongside the email, with little difference to how they want to do things currently and not unlike the way they process and present image attachments or PDF previews or what-have-you. Embedding it within the email not only disadvantages those not using the big email clients (as we've all seen embrace/extend in action, right?) but it places ones email provider in the middle of a non-email exchange between the user and another service. If anything, the way functionality has been created in 2013 is exactly why we should take care to not see things like this become a carrot for data silos.
  - dragonwriter 13y ago
    > The filetype is more than the encoding. HTML isn't an encoding, and HTML is the filetype in which the structured data used for schemas-in-email is embedded, using open standards for embedding various kinds of data in HTML. > And should a given client not be aware of these 'actions', using a file-type enables the host system to present an application or extension that is. It is now quite common for systems that handle HTML to provide mechanisms for extension to provide additional functionality that don't rely on segregation of related data into separate files with separate types. > Embedding it within the email not only disadvantages those not using the big email clients Parsing microdata and JSON-LD isn't exactly difficult; obviously Google specifically as the first mover has some advantage, but I don't see how this disadvantages any other client any more than any new feature a client implements. > but it places ones email provider in the middle of a non-email exchange between the user and another service. How is it a "non-email exchange"? Its an exchange conduct through email. That's an "email exchange". > If anything, the way functionality has been created in 2013 is exactly why we should take care to not see things like this become a carrot for data silos. How is the completely-open framework involved a "carrot for data silos"? You keep asserting conclusions without explaining your rationale.
    - roc 13y ago
      > "It is now quite common for systems that handle HTML to provide mechanisms for extension to provide additional functionality" Yes, that's the point. Embrace/Extend is part of the risk. The pitfalls have been shown before. We're supposed to learn from these things. > "I don't see how this disadvantages any other client any more than any new feature a client implements" There's a line between client features and proposed extensions of standards. e.g. everything Mailbox has done is fundamentally different from Google's 'Actions'. If you can't see that difference, it might explain why you don't see any problems. > "How is it a "non-email exchange"?" When I write a review for a Netflix movie I just returned, it has nothing to do with email or my email provider. Period. Today, Netflix sends me an email letting me know they got their disc and including a helpful link in the email should I want to write a review. I can click that link and exchange data with Netflix. Under this proposal, the mail provider brokers the exchange of data from myself to Netflix. It allows (in this case) Google to index not only that I got an email from Netflix, but without my doing anything, they're provided (in an easily machine-readable form) data that indicates the very precise meaning of that message. And should I click to review, they're provided with all the data I use to respond to those very-machine-readable questions. Reviewing a movie I've just watched is a follow-on interaction, that may have been raised by the email, but has little to do with it. It ought be no different from my reading and interaction with an attached PDF or image, or adding a calendar invitation, or anything else. For those of us who are on board with the modern "let's give large data silos all our data so they know everything about us" approach - this might sound like something between a non-issue and a desirable result. But not everyone is on-board with such an approach. And making that the default interaction that non-technical users are presented, and adding additional overhead for anyone who would rather not fork ever more data over to the data silos, it is not a 'feature'. > "How is the completely-open framework involved a "carrot for data silos"?" Under the guise of adding 'features' (carrot), providers are going to be able to much-more-easily harvest much-more personal data from users, even without those users doing anything, over the current state of things. And, again, there's no reason a properly Unix-y/Internet-y architectural solution to this same problem couldn't have been chosen. Such an architecture would present zero difference in functionality or interaction for those who are fine with the silos. But massive differences in usability and interaction for those who are not, those who don't know the difference and those who use mail clients that aren't tirelessly maintained. e.g. Presenting this data as an attachment that can be opened by programs other than the email client, in a context separated from the email provider. So those that want to use a better/safe/more-accessible tool to display/process these forms can choose to do so, regardless of what they choose to read their email with and regardless of whether that client is/can be updated as fast as the user desires. That this proposal is "open" only means that any particular silo is encouraged to support it, no different from, e.g., any other proprietary extension to css or html.

by roc 13y ago

dragonwriter 13y ago

> So... you're saying it should have been conceived of as a particular file type and attached, like all other non-message-related elements? No, if I was saying that, you would have seen those words in my message rather than yours. If you want to say that, go ahead, but don't misattribute it to me. But if you were to make that argument, I'd probably point out that its not "non-message-related" (actually, the biggest problem I have with it -- at least with the examples -- is that rather than adding semantic markup to the main content its all done by adding largely-redundant markup to the <head> element of the main content; I'm not sure if this is required, though, and I would hope it isn't since schema.org microdata doesn't normally require this mechanism, and this style is an uncomfortable hybrid between separate attachments than embedded semantic context.) And the file type is HTML. I don't see why an additional filetype is needed for this. > Would Google encode a vcf file in JSON and embed it in the message? I would be very much unsurprised if Google expanded its schemas-in-email support to include the schema.org Person type [1] and related types needed to support it, which provide the functionality provided by vCard (and a lot more). Since, after all, Google already supports that schema type for rich snippets in search. [1] http://www.schema.org/Person http://www.schema.org/Person > How is handling VCF different than handling other optionally-actionable data? vCard was a solution that was well adapted to the state of internet communications in 1995, but not necessarily the best model for new functionality in 2013.

roc 13y ago
> "No, if I was saying that, you would have seen those words in my message rather than yours." No-one was 'misattributing' anything to anyone. It was a figure of speech. Welcome to the sarchasm my friend. > "its not "non-message-related"" A bad word choice on my part. it is indeed message related; I was just (poorly) trying to draw a line between the message itself and the potentionally-actionable addenda. This whole project seems like an unnecessary marriage of the two. > "I don't see why an additional filetype is needed for this." For the same reason we have vcf even though it just happens to be particularly-formatted text. The filetype is more than the encoding. It's a hint to the client and the operating system as to how something should be handled. And should a given client not be aware of these 'actions', using a file-type enables the host system to present an application or extension that is. Again, not unlike VCF. "Aware" clients could process and present these 'actions' alongside the email, with little difference to how they want to do things currently and not unlike the way they process and present image attachments or PDF previews or what-have-you. Embedding it within the email not only disadvantages those not using the big email clients (as we've all seen embrace/extend in action, right?) but it places ones email provider in the middle of a non-email exchange between the user and another service. If anything, the way functionality has been created in 2013 is exactly why we should take care to not see things like this become a carrot for data silos.
- dragonwriter 13y ago
  > The filetype is more than the encoding. HTML isn't an encoding, and HTML is the filetype in which the structured data used for schemas-in-email is embedded, using open standards for embedding various kinds of data in HTML. > And should a given client not be aware of these 'actions', using a file-type enables the host system to present an application or extension that is. It is now quite common for systems that handle HTML to provide mechanisms for extension to provide additional functionality that don't rely on segregation of related data into separate files with separate types. > Embedding it within the email not only disadvantages those not using the big email clients Parsing microdata and JSON-LD isn't exactly difficult; obviously Google specifically as the first mover has some advantage, but I don't see how this disadvantages any other client any more than any new feature a client implements. > but it places ones email provider in the middle of a non-email exchange between the user and another service. How is it a "non-email exchange"? Its an exchange conduct through email. That's an "email exchange". > If anything, the way functionality has been created in 2013 is exactly why we should take care to not see things like this become a carrot for data silos. How is the completely-open framework involved a "carrot for data silos"? You keep asserting conclusions without explaining your rationale.
  - roc 13y ago
    > "It is now quite common for systems that handle HTML to provide mechanisms for extension to provide additional functionality" Yes, that's the point. Embrace/Extend is part of the risk. The pitfalls have been shown before. We're supposed to learn from these things. > "I don't see how this disadvantages any other client any more than any new feature a client implements" There's a line between client features and proposed extensions of standards. e.g. everything Mailbox has done is fundamentally different from Google's 'Actions'. If you can't see that difference, it might explain why you don't see any problems. > "How is it a "non-email exchange"?" When I write a review for a Netflix movie I just returned, it has nothing to do with email or my email provider. Period. Today, Netflix sends me an email letting me know they got their disc and including a helpful link in the email should I want to write a review. I can click that link and exchange data with Netflix. Under this proposal, the mail provider brokers the exchange of data from myself to Netflix. It allows (in this case) Google to index not only that I got an email from Netflix, but without my doing anything, they're provided (in an easily machine-readable form) data that indicates the very precise meaning of that message. And should I click to review, they're provided with all the data I use to respond to those very-machine-readable questions. Reviewing a movie I've just watched is a follow-on interaction, that may have been raised by the email, but has little to do with it. It ought be no different from my reading and interaction with an attached PDF or image, or adding a calendar invitation, or anything else. For those of us who are on board with the modern "let's give large data silos all our data so they know everything about us" approach - this might sound like something between a non-issue and a desirable result. But not everyone is on-board with such an approach. And making that the default interaction that non-technical users are presented, and adding additional overhead for anyone who would rather not fork ever more data over to the data silos, it is not a 'feature'. > "How is the completely-open framework involved a "carrot for data silos"?" Under the guise of adding 'features' (carrot), providers are going to be able to much-more-easily harvest much-more personal data from users, even without those users doing anything, over the current state of things. And, again, there's no reason a properly Unix-y/Internet-y architectural solution to this same problem couldn't have been chosen. Such an architecture would present zero difference in functionality or interaction for those who are fine with the silos. But massive differences in usability and interaction for those who are not, those who don't know the difference and those who use mail clients that aren't tirelessly maintained. e.g. Presenting this data as an attachment that can be opened by programs other than the email client, in a context separated from the email provider. So those that want to use a better/safe/more-accessible tool to display/process these forms can choose to do so, regardless of what they choose to read their email with and regardless of whether that client is/can be updated as fast as the user desires. That this proposal is "open" only means that any particular silo is encouraged to support it, no different from, e.g., any other proprietary extension to css or html.