Make all metadata optional in AMP.

[cramforce]

Related to #499

[jmadler]

Does the validator currently check against this requirement?

[cramforce]

I don't believe it does. Labeled this issue to check.
On Oct 12, 2015 5:41 PM, "Jordan M. Adler" notifications@github.com wrote:

Does the validator currently check against this requirement?

—
Reply to this email directly or view it on GitHub
#593 (comment).

[erwinmombay]

reassigning to @powdercloud to answer the validator question

[kevinmarks]

What's the goal of requiring the article type here? In the search demo I can see that the image, headline published date and publisher logo were used to create the SERP previews, but not what role the explicit article type plays.
We've been looking into content-driven post type determination as part of the w3c SocialWG work - see http://indiewebcamp.com/post-type-discovery for current thinking.

Possibly more useful would be a deterministic algorithm for constructing SERP previews of that type, with examples drawn from existing pages.

[cramforce]

How things get marked up to show up in Google Search is a Google issue. The
AMP project doesn't care. Stuff like that should be documented in a Google
help center article.

The reason why I think marking up the type is useful is that browsers could
use that to make similar heuristic decisions as AMP, so they could optimize
things and we no longer need AMP. Maybe we don't need it. I'd be fine to
drop the requirement, but I think it'd be a net win.
On Oct 12, 2015 9:24 PM, "Kevin Marks" notifications@github.com wrote:

What's the goal of requiring the article type here? In the search demo I
can see that the image, headline published date and publisher logo were
used to create the SERP previews, but not what role the explicit article
type plays.
We've been looking into content-driven post type determination as part of
the w3c SocialWG work - see http://indiewebcamp.com/post-type-discovery
for current thinking.

Possibly more useful would be a deterministic algorithm for constructing
SERP previews of that type, with examples drawn from existing pages.

—
Reply to this email directly or view it on GitHub
#593 (comment).

[tantek]

"The reason why I think marking up the type is useful is that browsers could use that to make similar heuristic decisions as AMP, so they could optimize things and we no longer need AMP. Maybe we don't need it. I'd be fine to drop the requirement, but I think it'd be a net win."

Key phrases you used:

• "browsers could use"
• "they [browsers] could optimize"
• "maybe we don't need it"
• "fine to drop the requirement"

Then why not drop the requirement until a browser implementer comes forward with a concrete use-case that needs it (rather than "could")? A simpler spec (fewer requirements) is a better spec.

And as @kevinmarks indicated, there's a good chance we can nullify any such direct need for explicit typing through a concrete Type Discovery algorithm, developed naturally based on (cited) real world publishing experience.

[cramforce]

No need to quote my words out of context. That comes across rather
impolite. If there are good arguments to fully drop the requirement I'm
very open to drop it.

If people would prefer to continue the right to not use semantic markup in
their pages that is fine with me.
On Oct 12, 2015 9:47 PM, "Tantek Çelik" notifications@github.com wrote:

"The reason why I think marking up the type is useful is that browsers
could use that to make similar heuristic decisions as AMP, so they could
optimize things and we no longer need AMP. Maybe we don't need it. I'd be
fine to drop the requirement, but I think it'd be a net win."

Key phrases you used:

• "browsers could use"
• "they [browsers] could optimize"
• "maybe we don't need it"
• "find to drop the requirement"

Then why not drop the requirement until a browser implementer comes
forward with a concrete use-case that needs it (rather than "could")? A
simpler spec (fewer requirements) is a better spec.

And as @kevinmarks https://github.com/kevinmarks indicated, there's a
good chance we can nullify any such direct need for explicit typing through
a concrete Type Discovery algorithm, developed naturally based on (cited)
real world publishing experience.

—
Reply to this email directly or view it on GitHub
#593 (comment).

[tantek]

No need to tone-police. My point was your words justified the opposite of your conclusion.

The burden of proof of any feature (requirement) in a spec is for its existence, dropping is the default choice because simpler specs tend to be better, more secure, easier for authors etc.

Without a good real world use-case based argument for why any particular markup (semantic, meta, or otherwise) is needed, there's no justification for requiring it. Less is better. Otherwise it's just bloat.

[powdercloud]

The validator itself isn't checking, it just allows it. Reason being we're not parsing up the json thus far.

However de facto for the preview release I believe the articles do have the markup, and some other code (not the validator) is looking for this markup.

My hunch is that it's useful to put some markup about the articles into the spec (headline, author, etc.) because it lowers the barrier of entry for anyone to deliver these articles: No need for fancy detection algorithms or parsing stuff like headline, author, publishing date from the contents.

[cramforce]

@tantek I will strictly enforce a be-excellent-to-each-other code-of-conduct on this open source project. You were escalating a discussion that really had nobody really disagreeing heavily with each other. I can be very much convinced to remove all semantic markup requirements from the AMP spec. I think your spec simplicity argument is great!

@powdercloud That hunch is a pretty good one, I think. Mandating baseline semantic markup helps smaller AMP consumers that cannot effectively mandate markup themselves (like Google, Bing, Yandex, Twitter Facebook) to get predictable structured data. I think practically speaking there are pretty good libraries that just extract from a page what they get get independent of whether the author used schema.org, OGP or Twitter cards, so it doesn't really matter all that much.

[kevinmarks]

There are no public libraries I know of that parse schema.org; last time I asked danbri he said that they don't exist. https://twitter.com/danbri/status/616164347073662976
If you know of one I'd love to hear about it.

[cramforce]

CC @danbri

[cramforce]

Updated to remove all metadata requirements.

[danbri]

Oh, how I have missed these debates!

[dvoytenko]

LGTM