w3c
Setting up the echidna action
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?
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.
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. https://github.com/w3c/respec-mermaid/commit/1d8ea4847ad85906458e990ab155f6306d1c09b3#diff-7ae45ad102eab3b6d7e7896acd08c427a9b25b346470d7bc6507b6481575d519R20 through https://github.com/w3c/respec-mermaid/commit/546baa987e62ad2e33dbcb5fe2cd428372885546
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.
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 https://github.com/mermaid-js/mermaid/issues/1766#issuecomment-2608267333 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.
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...
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.
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.
Kevin, can you try making a PR with that substitutions (<br> to <br/>)?
https://github.com/w3c/respec-mermaid
Hooboy, this was a fun one...
The br tag issue is not a bug. See my comment on the issue in the Mermaid repository.
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.
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…
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
foreignObjectcontent 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.
@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?
@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 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.
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
Now, looking a bit more into that issue, if the
foreignObjectelement 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.
@iherman We're looking into it further. @jandrieu and I may have found a way to patch the Mermaid code to fix the problem.
@iherman @jandrieu See https://github.com/speced/respec/pull/5003. Replaces previous PR on ReSpec Mermaid.
@iherman @brentzundel Can get some support for resolving https://github.com/speced/respec/pull/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 <BR> errors from different workarounds.
This is currently blocking the publication of an updated VC Use Cases document.
@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 https://github.com/w3c/vc-use-cases/pull/161#issuecomment-3003696273. Any advice on how to proceed quickly would be welcome...
@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...
@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
@iherman Please rerun the action. The logs have expired, and I need the output to trace the error again.
@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.
@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.
@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.