[whatwg] header for JSON-LD ???

[Melvin Carvalho]

On 26 July 2017 at 15:43, Mark Kaplun <mark at marksw.com> wrote:

> Well, in practice, since it is an SEO signal what google does in practice
> is more important than any theoretical discussion.
>
> Not being in any way affiliated with google, my own impression is that
> google do not care which format you use as long as it can be parsed by
> them.
>
> The main problem with the metadata that I see as a developer is that it
> bloats the HTML, while adding very little value to the human browsing the
> web page, this means that pages are being served slower which is probably a
> bigger concern on mobile and slower networks.
> One thing that google support with JSON-LD is asynchronous loading of it.
> Basically the HTML is loaded first, and at some point you can have some JS
> that will load the JSON by an AJAX request. google is happy to get the
> JSON-LD this way, to the human eye the page loads fater, the only thing not
> being solved is that there is still communication bloat even if now it is
> divided into two requests instead of one.
>

While this is typically true of today's browsers, which are human
oriented.  I have been experimenting for some time with a next generation
browser (via addon/shim) which can view both human readable data and
machine readable data.  Typically what you would do is take the data, and
pass it over to a 'viewer' which acts as a display app.  I've had very good
experiences with this.   My personal hope is that data browsing will become
more common over time, so instead of seeing JSON as plain text, or a tree,
it will come a bit more to life as browsers get more features.


> I assume that what Micheal was trying to say is that instead of hacks as
> described above, it might be a better thing to be able to specify in some
> way where the JSON-LD is located (link with relevant rel attribute ?).
>
> just my 2 cents. I currently work in a team that develops a meta data
> plugin for wordpress that utilizes JSON-LD. I do not claim to fully
> understand the historical reasons why things are like they are right now.
>
>
> On Wed, Jul 26, 2017 at 4:04 PM, Jonathan Zuckerman <j.zuckerman at gmail.com
> >
> wrote:
>
> > 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.
> >>> >
> >>>
> >>
>