Respec export problem with the script

[iherman]

Look at an example in the VCDM spec:

• https://w3c.github.io/vc-data-model/#example-usage-of-the-id-property

It works fine. But look at the same example in the published version:

• https://www.w3.org/TR/vc-data-model-2.0/#example-usage-of-the-id-property

All the vc tabs are empty. It is not a /TR problem; if you manually export the document from respec, the generated code is similar.

Interestingly, the VCDM echidna process properly finishes, and there is an update on /TR. In the case of the VC Overview document, although the echidna action on the repository completed, the document is not update on /TR and I do not know why. But it is while looking at that issue that I realized there is a problem with echidna. Maybe there is a relationship between the two and, if so, we may get some more internal reports from Denis if necessary.

[msporny]

If I had to guess, I think the rendering process for the tabs changed to "generate content on click". If that's the case, then the "click" is never registered when ReSpec is run in a headless setting, leading to the blank examples in the TR version.

/cc @BigBlueHat @tminard who might know more about this change?

[iherman]

If I had to guess, I think the rendering process for the tabs changed to "generate content on click". If that's the case, then the "click" is never registered when ReSpec is run in a headless setting, leading to the blank examples in the TR version.

I am not sure that is the issue, although I am only vaguely familiar with the internal guts of respec. But the tabs get empty even if I export the respec file into HTML from my browser, which seems to contradict this.

[iherman]

It seems that the situation is still not solved 😒

I concentrated on Example 3 in the VCDM spec.

• In the editors' draft, all tabs work.
• I export the file locally from Respec repeatedly (to be sure, I cleared the browser cache for the file before doing anything else).
• In the same example, some tabs work, some are empty. Which works seems to be random: in one run ecdsa and eddsa worked and all the others empty, but in the other case only ecdsa-sd work and all the other are empty.

We seem to have a race condition... 😒

[iherman]

Any news on this, @BigBlueHat ? Our specs on /TR are wrong...

[iherman]

Guys, is there any progress with this?

At this moment, in the July 21 edition of VCDM, the example still does not render properly (and it is the same for other cryptosuite tabs in the document).

@msporny @tminard @BigBlueHat ?

[decentralgabe]

Not sure how to debug this but running into this for VC-JOSE-COSE /TR too https://github.com/w3c/vc-jose-cose/issues/286

[msporny]

Also cross-posted here (where I responded): https://github.com/w3c/vc-data-model/issues/1538

[BigBlueHat]

@iherman this was fixed awhile back. It looks like the VCDM spec, at least, had not been updated to use the v3.3.2 release. I've sent a PR to that end at https://github.com/w3c/vc-data-model/pull/1540

@decentralgabe that should be all that's needed on your end also. I noticed you tried to cut a release via GitHub's releases feature, but @msporny had already shipped everything but that last commit as v3.3.2. I'm fine if we ship more often, but we should coordinate on how/when. Manu's approach involves some special branch making containing the dist/ folder which the GitHub releases feature won't have/make. We can (and should) come up with a repeatable release process...ideally involving robots to do this stuff for us. 😀

[BigBlueHat]

I'm closing this as fixed, but please reopen (or open new issues) if/as needed. Thanks! 🎩

[decentralgabe]

@BigBlueHat agree on a better process or automation here. I will attempt the instructions Manu laid out in #39 for 3.3.3

[msporny]

This bug remains, reopening: https://github.com/w3c/vc-data-model/issues/1538#issuecomment-2280483855

[BigBlueHat]

Not able to reproduce that error (i.e. empty tabs). I tested in Firefox, Chrome, and Edge. At this point, I'm wondering if a browser extension may be interfering. @iherman you may want to try private browsing and/or a clean browser profile (sans extensions) to be sure nothing else is interfering with your local rendering.

[iherman]

@BigBlueHat I am happy to test this tomorrow. But... when you run through echidna, there is no extension involved, not even any traditional browser. And that doesn't work either, see the VCDM spec on /TR.

[BigBlueHat]

@BigBlueHat I am happy to test this tomorrow. But... when you run through echidna, there is no extension involved, not even any traditional browser. And that doesn't work either, see the VCDM spec on /TR.

Right. My bad. I'd thought you were also seeing the breakage locally.

It does look like Echidna is stripping things out though... https://github.com/w3c/vc-data-model/issues/1538#issuecomment-2284689485

Not sure how to avoid that as I've never worked directly with Echidna.

[iherman]

FWIW, I tested it on an "unspoiled" Chrome browser (ie, no extensions) by making an export of the editors' draft on my machine. The result is indeed o.k., the vc-respec output is there. The problem seems to be the way it is done with echidna.

[iherman]

Actually... just to be precise. The issue is not echidna. Echidna generates the final version using the "headless" version of respec at W3C labs. Consider the following URL: https://labs.w3.org/spec-generator/?type=respec&url=https://w3c.github.io/vc-data-model/?specStatus%3DCRD. That is the way to generate the static version of the document (whose result is then pushed onto /TR by echidna). And, guess what? The URL above has the same problem: the vc-respec output is missing.

cc @msporny

[BigBlueHat]

@iherman looks like spec-generator calls Respec's toHTML() with some additional options: https://github.com/w3c/spec-generator/blob/main/generators/respec.js#L14-L18

Not yet found what may be stripping those values, though...but I'll keep looking.

[BigBlueHat]

My current guess is that it's something like this: https://github.com/speced/respec/issues/4498#issuecomment-1655399819

Essentially, the referenced function is being run and returns null right away rather than being awaited. I can make that async...and see if that fixes it...but really not sure how to test this sanely...which is the harder part of this situation at the moment.

[BigBlueHat]

So, I've found this is easily reproduceable using respec on the command line, so no need for more tooling locally. Now to figure out what respec actually wants...

[BigBlueHat]

@iherman please give #42 a try. We can make a release once that's merged.

For the record, postProcess always ends up full of null values...it's a red herring. The actual issue was indeed some async code not being awaited now that we switched away from the onclick experience.

It's all better now. 😺

[iherman]

I am not sure how to test it on my side. How can I link to the right version of respec-vc from my document so that I can test locally (ie, making an export from the browser)?

[msporny]

Respec v3.3.4 has been released. The good news is that the latest publication seems to have fixed the async issues for MOST of the tabs. The latest release also seems to have broken the COSE tab. :((( /cc @BigBlueHat @decentralgabe

[msporny]

We clearly need release/merge tests to ensure that ReSpec is generating the examples as expected. We've done 3-4 broken releases now where we thought things were working, and they weren't.

[BigBlueHat]

Bit of a hacky fix, but moving the sd-jwt tab to be the last one solved the hidden cose content problem: https://github.com/w3c/respec-vc/pull/45

I'll make an issue for @decentralgabe or someone to address the HTML being output in the sd-jwt tab--which seems to be what was causing the cose tab content to be hidden (as best I can guess...).

[decentralgabe]

thanks @BigBlueHat for the effort, I can take a closer look

[BigBlueHat]

Fixed in https://github.com/w3c/respec-vc/releases/tag/3.3.5