Re: API design principles - HTMLXML literals

Hi James,

On 12 Oct 2015, at 13:12, james anderson <james@dydra.com> wrote:

> good afternoon john,
> 
>> On 2015-10-12, at 10:56, John Walker <john.walker@semaku.com> wrote:
>> 
>> Hi Rob,
>> 
>>> On October 11, 2015 at 11:28 AM Robert Sanderson <azaroth42@gmail.com> wrote:
>>> 
>>> 
>>> The approach that we have taken in the Web Annotation Working Group [1] (and
>>> elsewhere) is to have an embedded resource with value, language and format
>>> properties:
>>> 
>>> {
>>>   "@type": "EmbeddedContent",
>>>   "value": "<span>This is some <b>marked up</b> content.</span>",
>>>   "language": "en",
>>>   "format": "text/html"
>>> }
>>> 
>>> As RDF 1.1 does not allow both language and format to be associated with a
>>> literal value, this is the best that we could do.
>>> 
>>> Hope that helps,
>>> 
>> 
>> Thanks for the input.
>> Very relevant as we also need to deal with multilingual content.
>> Did you consider to put the lang="en" attribute in the HTML?
>> If so, what was the reason to go for chosen approach?
>> 
>> Brings up some interesting questions about if we might look at language-based
>> content negotiation.
> 
> there is an Accept-Language header, but the metadata for that would have to be per document v/s per term as it operates at a different protocol level.

Sure, that would be ok

> 
>> Would be nice in theory, but not sure how widely this is supported.
>> Also considering the translation processes, the different languages could well
>> be based on different
>> versions of the primary content, how to deal with this in a clean manner?
> 
> Accept-Version analogous to the Accept-Datetime which memento introduced, but with additional parameters beyond an atomic designator to apply to version metadata?

The requirement we want to support is to enable a client to discover that the translated content is based on a superseded version of some source content. In other words: which of the translations are outdated.

> 
> best regards, from berlin,
> ---
> james anderson | james@dydra.com | http://dydra.com
> 
> 
> 
> 
> 

Cheers,
John