[whatwg] header for JSON-LD ???

[Mark Kaplun]

hmmm http://blog.schema.org/2013/06/schemaorg-and-json-ld.html

If you use a CMS like wordpress for your content, and you are just a
content person, it is a big meh to try to add manually the attributes, and
it is also a meh to develop software that will need to parse the content to
add it as you might break the structure required for the proper functioning
of CSS and JS. You can have all kinds of "macros" for that, but the result
is unreadable content on the editing side.

Whatever are the cons of disconnecting the data from the content, it is
probably more likely that you will have the data, or at least it will be
more complete if you can use json-ld as it is easier to manage.

On Wed, Jul 26, 2017 at 3:11 PM, Jonathan Zuckerman <j.zuckerman at gmail.com>
wrote:

> I agree that reducing the bloat of JSON-LD is a noble goal. Sorry to
> belabor this point, but can you explain why JSON-LD is needed in the first
> place? I've tried to point out that HTML is capable of doing it without
> another spec, which obviates the need for content duplication and bloat
> that JSON-LD introduces (and the extra headers you are suggesting). To your
> other example, CSS media queries can be employed by authors to respect user
> preferences for reduced motion or other visual features. This makes a lot
> of sense because it colocates those rules in the place where the
> problematic feature would be defined in the first place. Why should a
> problem introduced by CSS be fixed by some other technology?
>
> What I'm saying is that there are alternatives to JSON-LD which are
> superior and (this is crucial) already supported globally. I'm confident
> that we can expand the scenarios endlessly and still not come across one
> where JSON-LD accomplishes something HTML couldn't already do better. Can
> you explain why you are such a fan of JSON-LD? I'm open minded, I'm ready
> to be convinced, but I feel like I've suggested obviously superior
> alternatives to each of the use cases you've presented (if I missed any,
> please remind me and I'll be happy to circle back) I was honestly quite
> ambivalent about JSON-LD when this discussion started but I'm convinced now
> that it's a bad direction for the web.
>
> In case you haven't seen it, schema.org suggests an approach to structured
> data that works with HTML instead of sidestepping it. Google provides
> a Structured
> Data Testing Tool <https://search.google.com/structured-data/testing-tool>
> so you can be sure that the search engine is interpreting the cues
> correctly.
>
> Ok so, I think I've made clear my opinion of JSON-LD ;) taking a big step
> back, no action can be taken by the WHATWG about the new header because
> those are defined (a quick web search reveals) by the IANA and IETF. The
> header you suggest can be implemented at any time by website owners, you
> just need to bring this up with the search engines so their bots start
> sending the appropriate header. If you can get search engines on board (or
> convince enough site owners to only return JSON-LD when the appropriate
> request header is present so the search engines are forced to send it) then
> your job will be done.
>
>
> On Tue, Jul 25, 2017 at 18:41 Michael A. Peters <mpeters at domblogger.net>
> wrote:
>
> > On 07/25/2017 02:42 PM, Qebui Nehebkau wrote:
> > > On 25 July 2017 at 17:32, Michael A. Peters <mpeters at domblogger.net>
> > wrote:
> > >
> > >> Nor does his assumption that I am "new" to the web somehow disqualify
> me
> > >> from making suggestions with current use cases that could reduce the
> > bloat
> > >> of traffic.
> > >>
> > >
> > > Oh, then I think you misunderstood his statement. As I read it, "spend
> > more
> > > time working with the web you have before trying to change it" was a
> > > suggestion to look for a way to do what you want with current
> technology,
> > > not an argument that you don't have enough web experience. "Spend more
> > > time" on this particular project, not in general.
> > >
> >
> > I have a way to do what I want with current technology.
> >
> > I can detect bots based upon user agent and only send the JSON-LD when I
> > do so.
> >
> > However there are some things that may be of use to a browser with
> > accessibility functions, such as declarations regarding whether or not a
> > page (or resource on a page) has flashing content or has simulated
> > motion. So there are legitimate reasons why an end user client may want
> > the JSON-LD data before rendering a page.
> >
> > Just like the accept header for WebP, an accept header for JSON-LD could
> > solve this problem. Bots and non-bot users agents that want it send it.
> > Webmasters who understand people in undeveloped countries benefit from
> > non-bloated paged can then choose to only send the JSON-LD in their
> > pages when it is wanted.
> >
> > Much better to implement this now when JSON-LD is still relatively young.
> >
> > Whether JSON-LD is the best way to add structured data to a page
> > probably depends upon a lot of different factors, that's a different
> > discussion. But it is being used. That's the discussion, reducing the
> > drawbacks of bloated content for clients that ignore it anyway.
> >
>