Setting up the echidna action

[iherman]

The repository secret has also been generated and added to the repo

[iherman]

@msporny would be good if you checked it; a second pair of eyes is always helpful...

[iherman]

I presume the PR must be merged first before it can be used. The error check error seems to be a bootstrapping problem. @msporny wdyt?

[msporny]

I presume the PR must be merged first before it can be used. The error check error seems to be a bootstrapping problem. @msporny wdyt?

The error was because the server-based ReSpec build process failed. It's probably just a transient error; if the use cases document builds locally, it's probably fine.

[jandrieu]

We're going to accept this and see if it works once the commit is pushed.

[jandrieu]

Ok. We were able to get rid of the node.js error by updating the checkout task to v4.

However, now the failures are SVG complaints about rects without width & height.

This appears to be because of empty rects <rect></rect> and improper
inside a being generated by mermaid.

Can we get respec-mermaid bumped to the latest version? I believe @msporny took care of this last time.
w3c/respec-mermaid@1d8ea48#diff-7ae45ad102eab3b6d7e7896acd08c427a9b25b346470d7bc6507b6481575d519R20 through
w3c/respec-mermaid@546baa9

Although, to be fair, we have not verified that the latest mermaid has a fix for this. I'm reviewing their issue log to see if there's anything.

[jandrieu]

Digging into this further, we can definitively say that the mermaid is generating an improper <br> tag where it should be a <br/> tag.

We've escalated this in an existing issue at mermaid-js/mermaid#1766 (comment) but that issue is 4+ years old and we may not be able to get traction.

The other alternative is to turn off strict checking for SVGs, but we want to first try to get the mermaid fixed.

[iherman]

It should be possible to add a simple script that converts <br> tags to <br/>. It is possible to add script references to respec to be run before or after it goes through its processing.

The only point is that I am not sure how mermaid is exactly used within a respec file, ie, at which stage. I seem to remember that somebody from DB has done that (@msporny should know), so adding that script at the right place should be possible...

[msporny]

Yeah, we can fix this in respec-mermaid, someone just needs to raise the PR. It's not a difficult "fix", just need to find someone that has the bandwidth to do it.

[jandrieu]

I can verify that the previous configuration did not fail.

The output HTML does have a <br> in the middle of a span, but there's not complaint about it in the browser.

[jandrieu]

Kevin, can you try making a PR with that substitutions (<br> to <br/>)?

https://github.com/w3c/respec-mermaid

[ghost]

Hooboy, this was a fun one...

The br tag issue is not a bug. See my comment on the issue in the Mermaid repository.

[jandrieu]

It's a bug somewhere.

Looks like this is a bug in the validator.

How do we fix that?

p.s.
Great breakdown in the other issue.

[iherman]

It's a bug somewhere.

Looks like this is a bug in the validator.

How do we fix that?

p.s. Great breakdown in the other issue.

If my understanding is correct, the W3C publication tool runs an HTML validator which, inside, runs an SVG validator, and that SVG validator tries to handle/check the foreignObject content as XHTML as opposed to HTML. Is this the short summary of the bug?

I believe the person handling the validator problems is @deniak who is, hereby, pinged…

[deniak]

If my understanding is correct, the W3C publication tool runs an HTML validator which, inside, runs an SVG validator, and that SVG validator tries to handle/check the foreignObject content as XHTML as opposed to HTML. Is this the short summary of the bug?

I believe the person handling the validator problems is @deniak who is, hereby, pinged…

spec-prod runs validator.nu to check the spec. If there's a bug with the validator, an issue should be raised on the official repository.

[ghost]

Issue raised; see validator/validator#1816.

[jandrieu]

@deniak It's been two weeks since Kevin raised the issue over at the Validator with no response yet.

What are our options for disabling validation?

Or are we prevented from publishing until the Validator gets updated?

[TallTed]

@jandrieu @deniak @KDean-GS1 — Perhaps an update to the validator issue should be made, describing its impact? Reading what's there now, it doesn't appear to have any need for urgency on that side.

[deniak]

@deniak It's been two weeks since Kevin raised the issue over at the Validator with no response yet.

What are our options for disabling validation?

Or are we prevented from publishing until the Validator gets updated?

We have an exception mechanism in place but the exception needs to be approved first. Now, looking a bit more into that issue, if the foreignObject element includes elements from a XML namespace, then XML requires a opening/closing tags. So it's really not clear to me if this is a bug with the validator.
@svgeesus may know more on this.

[iherman]

Just re-launching this thread: it is becoming very important to fix this issue in some way or other and have the document properly published on /TR. Here is why: the FPWD for the Digital Credentials API specification is on its way to be published. That document refers to https://www.w3.org/TR/vc-use-cases/ as a collection of use cases. However, that URL dereferences to the old 2019(!) version of the use cases document, ie, to 6-year-old document. That is a blunder...

Setting up echidna would solve the issue right away.

Several of you got into the technical issues surrounding this problem; where are we? What is the shortest path to get something properly published soon? Is there anything I can do to help (there are already many cooks around...).

@brentzundel @jandrieu @msporny @KDean-GS1

[iherman]

Now, looking a bit more into that issue, if the foreignObject element includes elements from a XML namespace, then XML requires a opening/closing tags. So it's really not clear to me if this is a bug with the validator.
@svgeesus may know more on this.

In my experience with other specifications where we use svg diagrams, the svg portion must indeed be in proper XML syntax, and that includes the fragments within foreignObject. SVG is defined in XML, and I do not know of any version of SVG relying on the HTML syntax.

[ghost]

@iherman We're looking into it further. @jandrieu and I may have found a way to patch the Mermaid code to fix the problem.

[ghost]

@iherman @jandrieu See w3c/respec-mermaid#11.

[ghost]

@iherman @jandrieu See speced/respec#5003. Replaces previous PR on ReSpec Mermaid.

[jandrieu]

@iherman @brentzundel Can get some support for resolving speced/respec#5003?

Kevin figured out an ugly work around, but it works.

Our attempts to get the tooling stack to properly handle the embedded namespace has not succeeded. It appears that, in many places, these tools instantiate a DOM with the default namespace in a way that is not accessible to the tooling chain for customization. So we keep seeing the same
errors from different workarounds.

This is currently blocking the publication of an updated VC Use Cases document.

[iherman]

@iherman @brentzundel Can get some support for resolving speced/respec#5003?

Kevin figured out an ugly work around, but it works.

Our attempts to get the tooling stack to properly handle the embedded namespace has not succeeded. It appears that, in many places, these tools instantiate a DOM with the default namespace in a way that is not accessible to the tooling chain for customization. So we keep seeing the same errors from different workarounds.

This is currently blocking the publication of an updated VC Use Cases document.

@deniak you may be in position to get this thing moving... This issue has been open for a long time; at the moment, we seem to be unable to get the Use cases document published via echidna. It has become more urgent, see #161 (comment). Any advice on how to proceed quickly would be welcome...

[iherman]

@iherman @brentzundel Can get some support for resolving speced/respec#5003?

Kevin figured out an ugly work around, but it works.

Our attempts to get the tooling stack to properly handle the embedded namespace has not succeeded. It appears that, in many places, these tools instantiate a DOM with the default namespace in a way that is not accessible to the tooling chain for customization. So we keep seeing the same errors from different workarounds.

This is currently blocking the publication of an updated VC Use Cases document.

@KDean-GS1 @jandrieu I have pinged Denis, he might be able to move things ahead. In the meantime… I have not looked at the script details, but wouldn't it be possible to execute it locally on the generated source after the respec processing is done and before it is dumped into a final HTML file? I believe the postProcess hook of respec is making this possible. It would not handle the root cause of the issue, but it might make this document publishable...

[deniak]

@iherman @brentzundel Can get some support for resolving speced/respec#5003?
Kevin figured out an ugly work around, but it works.
Our attempts to get the tooling stack to properly handle the embedded namespace has not succeeded. It appears that, in many places, these tools instantiate a DOM with the default namespace in a way that is not accessible to the tooling chain for customization. So we keep seeing the same errors from different workarounds.
This is currently blocking the publication of an updated VC Use Cases document.

@deniak you may be in position to get this thing moving... This issue has been open for a long time; at the moment, we seem to be unable to get the Use cases document published via echidna. It has become more urgent, see #161 (comment). Any advice on how to proceed quickly would be welcome...

I've just commented on the issue but if the PR doesn't get merged, you should indeed be able to add a postProcess function to fix the <br>s

[ghost]

@iherman Please rerun the action. The logs have expired, and I need the output to trace the error again.

[iherman]

@KDean-GS1 this PR must be merged to really install the action. I'd prefer you do this. Then, I believe, it is actionable manually, but the safest is to go through a bona fide extra PR to see what happens.

[ghost]

@iherman Normally, it's possible to rerun a failed action within the "Actions" tab (I've done so before), but not, apparently, when the logs have expired. I'll create a dummy PR later this week.

[ghost]

@iherman I have created a new PR #165, but the action has been stuck in "Queued" status for over 15 hours now. I need someone with the necessary privileges to investigate why that is.

[iherman]

Sorry about this, @KDean-GS1, but I was out for a week on grandfather duty😀. At the moment, the only error message I see is "The job has exceeded the maximum execution time while awaiting a runner for 24h0m0s".

However. THIS PR must be merged first; it installs the action script itself. Without it nothing happens... So I will merge this now (it is Sunday morning on my watch.) and you should do dummy PR again to see if it works out.

[iherman]

This was discussed during the vcwg meeting on 17 August 2025.

View the transcript

w3c/vc-use-cases#161

<JoeAndrieu> w3c/vc-use-cases#161

JoeAndrieu: I want to check in regarding echidna in the use cases document.
… I want to be sure that if we need help from the group we have a chance to chat about it.

Brent: I think we should talk about this, but I want to setup a topic for it.

JoeAndrieu: KevinDean has been deepest into the code. Apparently none of the browsers or headless engines that we've checked correctly save the embedded namespace when dealing with the <br> tags.
… We're running into problems with validator.nu that is generating errors.

KevinDean: I've been through multiple layers of this with mermaid, respec-mermaid, fixing the br tag gets undone by whatever render engine is being used. That said, I have a full workflow set up, but need to get back to error that triggered the whole discussion, error logs are gone, need to create new PR to re-run everything.

KevinDean: That's on my plate at the moment.

brent: Months of effort have gone into trying to fix this problem, seems to be a respec problem, do we want to move to bikeshed?

KevinDean: I don't know, will have a better answer once I'm able to do end-to-end, most recent tests was accepted, br tag w/o slash, don't know what's different, need to re-run everything to see where things stand to decide on path forward.

manu: Switching to Bikeshed won't fix this particular problem. It's not a ReSpec bug, it's a problem mixing XML and HTML. Moving to Bikeshed would cost us the ability to use Mermaid directly in the specification.
… I expect it to be a problem given the incompatibilities between HTML5 and XHTML.

Brent: Kevin and Joe, see Manu as a resource to help with this.
… Let me know what you need as soon as you need it so we can continue to move this forward.
… Anything else on this or the use cases before we jump back into the data model?

---