[whatwg] header for JSON-LD ???

[Jonathan Zuckerman]

After reading just a bit more - it seems like JSON-LD and schema.org have
slightly different goals - schema.org suggests conventions for data cues in
HTML, JSON-LD suggests it for JSON (e.g. API responses for dynamic
websites) - exactly how "best practice" is this pattern of stuffing JSON-LD
into the script tag of an HTML document? Most of the articles I could find
on the subject come from Google, not the JSON-LD community...

On Wed, Jul 26, 2017 at 8:30 AM Mark Kaplun <mark at marksw.com> wrote:

> 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.
>> >
>>
>