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

Definition for frontmatter id tags #477

Closed
leobalter opened this issue Jan 24, 2016 · 8 comments
Closed

Definition for frontmatter id tags #477

leobalter opened this issue Jan 24, 2016 · 8 comments

Comments

@leobalter
Copy link
Member

As mentioned at #472 (comment):

@littledan: Rather than IDs which point to specific spec sections, I think it'd be much more useful to have ids that are the anchors within the document. These are much more likely to be consistent across releases. You could call these esids.

Based on this, and as it's easy to locate the section ids on tc39/ecma262 on each of the emu-clause tags, which are expected to be unique, I believe we can use the respective hash id for the Frontmatter's id and further versions:

id: sec-completion-record-specification-type

this value can be converted to links that could be found anywhere:

This reference works good and it's still compatible with the previous formats, as won't conflict with the recently adopted es7id: pending value, which can be easily replaced by id: pending and it's still useful for anything on Stage 3 and it's not on the draft yet.

@goyakin, do you like this idea?

@domenic
Copy link
Member

domenic commented Jan 24, 2016

I think it should just be "id"

@leobalter
Copy link
Member Author

Yes, it makes sense. I'll update the title and example.

@leobalter leobalter changed the title Definition for es{7,+}ids Definition for frontmatter id tags Jan 24, 2016
@goyakin
Copy link
Member

goyakin commented Jan 25, 2016

I think this is a good idea. The test harness doesn't use the current es6id, so we can start using the new one without any issues. I don't know if there's any other tool depending on es6id though.

I also agree with @littledan that this way we wouldn't have to keep up with changes in section numbers.

@littledan
Copy link
Member

+1

@jugglinmike
Copy link
Contributor

I'm a little late to the party, but I'd like to know more about the decision to use the name id instead of esid as suggested by @littledan. The latter is a few more characters, but I think it's preferable. Many tests will share the same value, and that contradicts commonly-held assumptions about "IDs". esid (or even specid) makes it clear that this value is reference to an identifier of some other document (and also gives a hint as to which document it refers).

There wasn't any discussion about why the change was made, so I thought I'd ask here.

@littledan
Copy link
Member

Any of those names sounds good to me.

@leobalter
Copy link
Member Author

I would like to reopen this issue.

After an internal - and informal - conversation with @jugglinmike and @rwaldron, It's been clear how id is giving a false impression it should hold an unique value for each test file. The other arguments to avoid id are well represented on Mike's argument.

It's still early to fix this up.

@leobalter leobalter reopened this Feb 18, 2016
@goyakin
Copy link
Member

goyakin commented Feb 18, 2016

@leobalter I'm OK with esid.

leobalter added a commit to bocoup/test262 that referenced this issue Feb 22, 2016
leobalter added a commit to bocoup/test262 that referenced this issue Feb 22, 2016
@leobalter leobalter mentioned this issue Feb 22, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants