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

Incorrect "wrong syntax" error reported when link to this version has trailing spaces #207

Closed
tidoust opened this issue Jun 10, 2015 · 1 comment
Assignees

Comments

@tidoust
Copy link
Member

tidoust commented Jun 10, 2015

If the spec to test contains trailing spaces in the href attribute of the "This version" and other "Previous version" links, Specberus reports errors such as:

  • Wrong syntax for This Version link.
  • error Short names differ between This and Latest Versions.
  • error Short names differ between This and Previous Versions.

Example of markup that triggers the issue:

<dl>
 <dt>This version:</dt>
 <dd><a href="http://www.w3.org/TR/2015/WD-presentation-api-20150610/ ">http://www.w3.org/TR/2015/WD-presentation-api-20150610/ </a>
 </dd>
 <dt>Latest published version:</dt>
 <dd><a href="http://www.w3.org/TR/presentation-api/ ">http://www.w3.org/TR/presentation-api/</a></dd>
 ...
</dl>

I don't have an example of an online spec because I'm going to update the version that I was testing. The thing is: Anolis generates this space, which is technically correct although a tad annoying perhaps, so it's not that easy to fix in the generated spec.

In the example, removing the final space before the closing double-quote in the href attribute fixes the issue. I suspect the code that would need to be tweaked is in lib/rules/headers/dl.js:

https://github.com/w3c/specberus/blob/master/lib/rules/headers/dl.js#L87

In particular, adding a call to trim() should do the trick but note it would have to be done for the latest link and the previous link as well:

var matches = ($linkThis.attr("href") || "").trim().match(new RegExp(vThisRex))
@tidoust
Copy link
Member Author

tidoust commented Jun 10, 2015

Hmm, actually, I was wrong, Anolis only produces the space if there is a similar space in the source text. In practice, Anolis generates the links based from text in the source spec that is in-between <!--begin-link--> and <!--end-link--> comments, and will just preserve the spaces that it found here. Anyway, the issue exists on Specberus, but I can easily fix it on my side, so not a priority at all.

tidoust added a commit to tidoust/presentation-api that referenced this issue Jun 10, 2015
I made a few changes to the raw spec to add the editors IDs, as required by
Echidna, to change the way version links are managed and to update the Status
of This Document section so that it might be used without modification in a
published Working Draft.

I also added a "wd" rule to the Makefile to generate a releases/WD.html that
can be provided to Echidna for immediate publication. The generated WD.html
file is not part of this commit but has been checked with success against
Specberus, the new pubrules checker.

Note that the Makefile now uses curl, grep and sed to extract the URL of the
latest published WD, used to compute the Previous Version link in the
generated Working Draft. This is all a bit hacky but should work and can be
manually checked and overwritten by someone before committing the new working
draft.

Also note that Specberus does not like trailing spaces in "href" in the
"This version" and other similar links. We have them because of a combinaison
of us using Tidy to enforce 80-character-long lines and Anolis that uses a
specific syntax based on comments for these links ("<!--begin-link-->" and
"<!--end-link-->"). I worked around that using Anolis "[VERSION]" and
"[LATEST]" substitution strings that do not get truncated in the source spec
and thus do not generate spaces in the end. The issue has been reported to
Specberus folks:
 w3c/specberus#207

I also added what I believe would be the right ECHIDNA manifest file for this
setting (need to test it for real by actually publishing the spec).

No "continuous integration" in this commit. There does not seem to be a way
to trigger Travis CI on particular changes made to a file. We may either use
tags, a different branch, or send the right "curl" command to Echidna manually
whenever we want to publish a Working Draft.
tidoust added a commit to tidoust/presentation-api that referenced this issue Jun 10, 2015
This commit should contain all updates needed to be able to publish working
drafts to /TR/ space at W3C on a semi-automated basis.

The basic principle is to use a dedicated "TR" branch where we generate the
Working Draft to publish. Any push to that branch will trigger Travis CI
(provided it is enabled on the repository, obviously) that will, in turn,
send a publication request to Echidna at W3C with the right parameters.

Actually publishing the spec from a local checkout of the gh-pages branch
should look like:

git checkout TR
git merge gh-pages
make wd
git add releases/WD.html
git commit
git push w3c TR

Using a separate branch is not stricto senso necessary. I chose that option:
1. to have Working Drafts remain somewhat hidden on GitHub, the gh-pages
branch will only contain the Editor's Draft and that sounds a good idea
2. because it is easy to trigger Travis CI on a specific branch but not when
a when a specific file is updated.

In terms of changes, I updated the raw spec to be publication rules and
Echidna compliant, adding the editors IDs, updating the way version links
are managed, and the Status of This Document section so that it might be used
without modification in a published Working Draft.

I also created a "wd" Makefile rule to generate the releases/WD.html file that
can be provided to Echidna for immediate publication. The generated WD.html
file is not part of this commit but has been checked with success against
Specberus, the new pubrules checker.

Note that the Makefile now uses "curl", "grep" and "sed" to extract the URL of
the latest published WD, used to compute the Previous Version link in the
generated Working Draft. This is all a bit hacky but should work fine in most
cases, except when publishing the spec more than once in a given day. The
"previous version" link can be manually checked and overwritten by some editor
before committing the working draft in any case.

Also note that Specberus does not like trailing spaces in "href" in the
"This version" and other similar links. We have them because of a combinaison
of us using Tidy to enforce 80-character-long lines and Anolis that uses a
specific syntax based on comments for these links ("<!--begin-link-->" and
"<!--end-link-->"). I worked around that using Anolis "[VERSION]" and
"[LATEST]" substitution strings that do not get truncated in the source spec
and thus do not generate spaces in the end. The issue has been reported to
Specberus folks:
 w3c/specberus#207

I also added what I believe would be the right ECHIDNA manifest file and the
right .travis.yml configuration file to automate the publication. This will
perhaps need to be adjusted when we try to publish the first working draft.
deniak added a commit that referenced this issue Aug 13, 2015
@deniak deniak self-assigned this Aug 13, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants