RE: On deploying next release of compatibility tables

Heya,

 

Regarding 1.:

Up to converter.convert(tableData) in index.js <https://github.com/webplatform/mdn-compat-importer/blob/master/index.js#L101> , the keys of the data object are MDN URLs, so there is no collision.

However convert does <https://github.com/webplatform/mdn-compat-importer/blob/master/lib/Converter.js#L123> : wpd.data[ec.getSlug()] = row; and getSlug just uses the part after the last slash, as it seems <https://github.com/webplatform/mdn-compat-importer/blob/master/lib/EntityConverter.js#L229> .

Maybe Renoir can tweak that a bit. Or, if the data is already missing in tableData, we need to tweak the HTML scraper (but unlikely, I think).

 

Regarding 2.:

That really comes down to how the EntityConverter handles <https://github.com/webplatform/mdn-compat-importer/blob/master/lib/EntityConverter.js#L253>  the conversion from the “HTML-JSON <https://github.com/webplatform/mdn-compat-importer/blob/master/lib/Converter.js#L14-35> “ to the “WPD-JSON <http://docs.webplatform.org/compat/compat-human.json> ”.

We can always modify this, so it can handle more possible values, which occur in the MDN compat tables.

 

 

P.S.: I’m currently pretty busy and generally unavailable, but I’m following the conversations. Just ping me and I’ll respond as soon as I can. :)

 

 

-fro

 

-----Original Message-----
From: Renoir Boulanger [mailto:renoir@w3.org] 
Sent: Freitag, 4. Juli 2014 20:32
To: Amelia Bellamy-Royds; David Kirstein
Cc: public-webplatform@w3.org
Subject: Re: On deploying next release of compatibility tables

 

Frozenice, can you do something about it?

 

 

How we can handle this:

 

I’m going to hold the deployment to after the community meeting.

 

Also, maybe we can deploy the change anyway, and just change the revised

compat data JSON after some more investigation.

 

What do you think?

 

(see notes in truncated thread below)

 

 

 

On 2014-07-03, 5:15 PM, Renoir Boulanger wrote:

> Nice Catch Amelia!

> 

> (...) 

> Frozenice, can you take a look at the issue Amelia raised?

> (...)

> 

> On 2014-07-03, 5:07 PM, Amelia Bellamy-Royds wrote:

>> (...)

>> From a quick skim-through there are a couple problems I can see:

>> 

>> 1. The JSON file doesn't distinguish between multiple

>> elements/properties with the same name within different namespaces or

>> languages.  E.g., the entries for "a" and "title" both reference the

>> SVG elements on MDN, not HTML elements (...)

 

This should already been addressed when Frozenice made the scraper.

 

I will change the scraper to list all keys in a JavaScript Array. That

way, we’ll see if what you are saying is true.

 

If we are actually losing data, we’d have to change the way we structure

the data.

 

>> 2. Some entries are showing up as "unknown" for Firefox, despite

>> having specific values in MDN.  E.g., see the text-shadow and

>> box-shadow pages.  I suspect the problem is that the MDN tables

>> include links to the release notes for the particular version number,

>> and this may be causing problems with the parsing function.

 

Yes, that is correct.

 

We are parsing the content and adjusting to have an harmonized first

version. The content has too much handmade notes in too many different

formats. We are using their data as a first import. We know it is not

perfect, nor complete; just a starting point.

 

You can see the parsing rules in the comments of the converter here [0]

 

  [0]:

 <https://github.com/webplatform/mdn-compat-importer/blob/master/lib/EntityConverter.js#L9> https://github.com/webplatform/mdn-compat-importer/blob/master/lib/EntityConverter.js#L9

 

Hope it clarifies things

 

-- 

Regards,

 

Renoir Boulanger  |  Developer operations engineer

W3C  |  Web Platform Project

 

 <http://w3.org/people/#renoirb> http://w3.org/people/#renoirb  ✪   <https://renoirboulanger.com/> https://renoirboulanger.com/  ✪  @renoirb

~