Re: [w3ctag/design-reviews] Serialization of natural language in data formats such as JSON [I18N] (#178)

Thanks @dbaron. While, in general, markup is a Good Thing for this, at the same time the point of using JSON and other data languages is the transmission of "unrendered" data. Let me give a concrete use case.

Suppose that in my day job I am building a Web page to show a customer's library of e-books. The e-books exist in a catalog of data and consist of the usual data values. It might looks something like:

```
{
    "id": "978-0-1234-5678-X",
    "title": "Moby Dick",
    "authors": [ "Herman Melville" ],
    "language": "en-US",
    "pubDate": "1851-10-18",
    "publisher": "Mark Twain Press",
    "coverImage": "https://example.com/images/mobidick_cover.jpg",
    // etc.
},
```

Each of the above is a data field in a database somewhere. Now, because I know I need it, I have language and direction information for each of the textual fields also in my database. I even have stuff like a pronunciation field for title and author (for sorting Chinese and Japanese). Those are just data fields. Do I really want to serialize them as HTML:

```
   "title": "<span lang='en-US' dir='ltr'>Mobi Dick</span>"
```

After all, I may not end up displaying the `title` field in an HTML context! My JSON might very well be used to populate say the device local data store which uses native controls to show the title.

I'd also argue that:

> a good bit of extra overhead for developers in the common case where they're not going to be interested in adding language or direction information

... is probably wrong. The common case where you don't want language or direction information is for non-language-bearing fields (`isbn`). Omitting the information for language-bearing fields is basically an I18N bug (yeah, being a pedant here)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/178#issuecomment-313783678