Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Spec URL Should be Normalized #3328

Closed
jpmedley opened this issue Jan 22, 2019 · 7 comments
Closed

Spec URL Should be Normalized #3328

jpmedley opened this issue Jan 22, 2019 · 7 comments
Labels
schema Isses or pull requests regarding the JSON schema files used in this project.

Comments

@jpmedley
Copy link
Contributor

The spec URLs in BCD should be normalized. In non-tech speech, this means deduplicate. This serves two purposes:

  • Eliminates duplication of data.
  • Adds insurance against stale data by providing a single location to update the URL.

An automated consistency check within a file cannot solve this problem because many interfaces contain members that contributed by multiple specs.

@ddbeck ddbeck added the schema Isses or pull requests regarding the JSON schema files used in this project. label Jan 22, 2019
@a2sheppy
Copy link
Contributor

What spec URLs in BCD? The only URLs commonly used in BCD are the mdn_url entries.

Assuming we really are talking about spec URLs though...

This is an interesting idea. I take it the idea is basically to have a table of specifications, with each spec's entry including its base URL, so that links to stuff within that spec are then written relative to that base URL. So something like...

SpecInfo.json

[
  ...
  {
    "id": "WebRTC",
    "name": "WebRTC 1.0: Real-time Communication Between Browsers",
    "url": "https://w3c.github.io/webrtc-pc/",
    "category": "Media"
  }
  ...
]

RTCPeerConnection.json

{
  "spec": "WebRTC",
  "api": {
    "name": "RTCPeerConnection",
    ...
    "spec_slug": "#rtcpeerconnection-interface"
  }
}

Something like that, anyway. I think I have missed the specific use case for this but the general idea is probably something like this for how it would be built, no?

@ddbeck
Copy link
Collaborator

ddbeck commented Jan 28, 2019

@a2sheppy the schema has spec_url (see: /schemas/compat-data.schema.json#L151) but it's undocumented. 😞

At least right now, it only appears to be used in /javascript/ data.

For more background: #1531 and #2983

@ExE-Boss
Copy link
Contributor

ExE-Boss commented Feb 1, 2019

I believe we should move SpecData.json to mdn‑data and reference it from here (like what I’m doing with GroupData.json in mdn/data#342).

@jpmedley
Copy link
Contributor Author

jpmedley commented Feb 1, 2019

@chrisdavidmills I think moving spec data is a good idea, but until the license issue is resolved this will prevent me from contributing to it.

@chrisdavidmills
Copy link
Contributor

@jpmedley this is an issue, certainly, which could perhaps be mitigated in a few ways (e.g. by getting W3C spec folks to add their own specs to our data), but really it would be so much better to sort out the license issue once and for all. I'll bring this up with our lawyer again and see if he managed tro make any headway with the discussion.

@foolip
Copy link
Contributor

foolip commented Feb 15, 2019

https://github.com/tobie/specref is a source of truth you could use for this, but I think you'll find some of the URLs still need massaging and getting them updating in specref can be difficult because it sometimes requires updating a page under https://www.w3.org/TR/.

I've dealt with this problem in https://foolip.github.io/day-to-day/ but not in a way that is maintenance-free.

@Elchi3
Copy link
Member

Elchi3 commented Mar 24, 2020

Closing this. We're not planning to do anything about this for now. Might come back in the future, when MDN is based on more structured data.

@Elchi3 Elchi3 closed this as completed Mar 24, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
schema Isses or pull requests regarding the JSON schema files used in this project.
Projects
None yet
Development

No branches or pull requests

7 participants