Hi Mike, On Tue, Feb 10, 2026 at 10:27 PM Mike Taylor <[email protected]> wrote:
> You already have approval to run the experiment (I am supportive too, > FWIW), but one question below: > > Technically, niche issues remain where in serialization, with the new Rust > parser we may occasionally insert an extra xmlns: element on a root element > due to API restrictions of the XML parser. This does not affect document > semantics. > > Can you say more about this? Does this mean the tests are bad (or just > useless in practice, since there are no semantic differences)? > The Rust XML crate has an API limitation in reporting namespace changes: The issue I reported upstream <https://github.com/kornelski/xml-rs/issues/48> contains a concrete example. In serialization (for example in View Source of an XML document) we have trouble reproducing the exact source document, because the parser does not tell us exactly where new namespaces are introduced or modified, it just gives us the summary inf the form of the currently valid namespace stack. To work around that I implemented a delta-computation in the glue code <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/xml/parser/xml_ffi.rs;l=74?q=xml_ffi.rs>. This is not perfect in reproducing exactly what is spelled out in the source document, but is sufficient for producing semantically identical serialized documents. With that limitation, we also have serialization issues in distinguishing documents that define the default xmlns and xml - prefixed namespaces explicitly, vs. those that don't. This is because the XML crate inserts those by default and we can't tell whether they came from the library defaults or from the source document. I checked again from running bots against the Rust parser used for everything <https://chromium-review.googlesource.com/c/chromium/src/+/7118958?checksRunsSelected=mac-rel&tab=checks> and I currently do not find that to be a practical limitation in the tests anymore. So, it does not matter much for testing because the tests can be modified and still work for what they were testing and it does not mean the tests are useless - but it shows a limitation in how accurately we can reproduce source documents. > From WPT tests we do not see other compatibility issues, and we believe we > can progress to real-world testing for the non XSLT scenarios. > > *Inline XSLT in SVG* > > There is a minor theoretical risk regarding standalone SVG images > (scenario 3 above) that utilize inline XSLT to transform raw XML data into > SVG. Example <http://rtsh.es/test/xml/svg_xslt_img.html> > > Data: UseCounters (XSLPIInSVGImage and XSLPIInSVGImageStandalone) > currently show 0% usage in Canary and Dev. > > It will be interesting to report on this in a future Intent to Ship - > after you get some stable exposure. > Yes, will do. Dominik -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAN6muBvuZw7vV2W6z09254%3DLsTuLh%2BoVy4-KDwG7kJtdNV7%3DzA%40mail.gmail.com.
