Re: API design principles - HTMLXML literals

Hi Asbjørn,

> > {
> > "@content": "http://schema.org/",
> > "@id": "#id",
> > "@type": "Product",
> > "mpn": "ABC123",
> > "name": "ACME thingamyjig",
> > "description": "the ACME thingamyjig is our <b>new</b> wonderful product
> > with
> > some <sub>subscript</sub> stuff.<br/>A new line"
> > }
>
> I'm still not familiar enough with Hydra to be able to express this,
> but I would instead make "description" a type with an "@id" pointing
> to where the HTML description can be downloaded and perhaps provide a
> plain text "@value" inline.

This can be done in a JSON-LD @context no need for Hydra, here that
would mean I could not use the standard Schema.org context.

[...]

> > However we do not see this second option as a widely deployed pattern.
>
> What do you mean? Is not conneg a widely deployed pattern? Or are you
> referring to something else?

Here I refer to most times the text is inlined in the JSON including tags
rather than pulled out into a separate external resource.

>
> > To go to other extreme, why not inline images as data URIs in the RDF?
>
> You can do that. RFC 2397 describes how.
>
> > Clearly this is possible, but quite uncommon.
>
> It is quite common in HTML e-mails and not unheard of on the web.
> Error pages in HTML, for instance, tend to bundle up everything they
> can inline so they are as self contained as possible, in order to
> successfully render a layout with CSS and images that don' depend on
> external (quite possibly failing) resources.

Yes indeed, I was meaning it is uncommon to do so in RDF.

>
> > Clearly developers are comfy with the idea of images as resources, but not
> > textual content.
>
> Most of the web consists of textual resources like text/html.
>
> --
> Asbjørn Ulsberg -=|=- asbjorn@ulsberg.no
> «He's a loathsome offensive brute, yet I can't look away»

Cheers,
John

Received on Saturday, 10 October 2015 17:10:00 UTC