Namespaces getting turned into hyperlinks when they are *not* links!

[RexJaeschke]

US-080 |   | 7.3.1 and throughout |   | Ed | Many strings that look like URLs but are namespaces or strings in examples have been treated as links. pack:// http %3c , ,www .openxmlformats .org ,my .container/ a/ b/ foo .xml www.openxmlformats.org should not have been a link Also, the entire string should not include any spaces.

Please fix throughout.

US-081 |   | 7.3.1 |   | Ed | An example with a URL in quotes has been turned into a link.  There are dozens of strings throughout the document that look like URLs that were not links in the source document but have been incorrectly turned into links.  Clause 7 has at least 35 instances of this problem.   No URL-like string in an example or enclosed in quotes should be a link.

Please fix.

US-082 |   | 7.5.2.1 and Annex E |   | Ed | Throughout the specification there are URL-like strings that represent XML namespaces.  Such strings are identifiers that serve a specific function in XML schemas and documents in XML markup.  They should not be treated as links.

Please fix.

US-089 |   | Annex E |   | Ed | The URL-like strings that represent namespaces and relationship types should not be links.

Please fix. |  

[murata2makoto]

ISO mimicked links in our PDF document. Such links were introduced when the PDF was created from our word document.

[murata2makoto]

We don't have to ask ISO. We only have to create PDF documents without harmful links.

[RexJaeschke]

2020-07-08 Teleconference

None of these pieces of text is a hyperlink in the Word field we submitted to ISO; however, they were hyperlinks in the PDF that was also submitted. How did that happen?

It turns out that using the latest version of MS Word on Windows, when Doing “Save As” to PDF, the only customizing options are via the Options button or the Tools drop-down list. And none of these provides any control over how hyperlinks might be handled when a URL-like piece of text is encountered. Unfortunately, by default all XML namespaces written as separate tokens get turned into hyperlinks, and there seems to be no way to alter that.

Action: Rex will take ownership of this issue and ask Tristan Davis if there is any solution.

[RexJaeschke]

After communicating with Tristan, here's what I found:

IS 29500 is an XML-related standard; as such, it makes use of XML namespaces, which have a form that looks a lot like a URL/URI. For example, http://www.openxmlformats.org/my.container. These must not be turned into hyperlinks, as they don’t lead to an internet resource, and none of them were made hyperlinks in the submitted Word file. However, the final Word document returned by ISO has them as hyperlinks. As best as we can tell, this was done (manually) by ISO editors based probably on what they saw in the PDF version of the submitted spec. Unfortunately, MS Word’s option “Save as PDF” results in these hyperlinks links being erroneously created, and there is no way to stop that from happening. Certainly, making them links was never the intention.

My understanding is that when we resubmit the Word document, we'll also have to send along a PDF rendering of it. And if I generate that from Word, I'm going to get the same unwanted hyperlinks back again, so we'll need to make sure that ISO is aware if this and that they should not turn them into hyperlinks again.

[RexJaeschke]

Comment: IS 29500 is an XML-related standard; as such, it makes use of XML namespaces, which have a form that looks a lot like a URL/URI. For example, http://www.openxmlformats.org/my.container. These must not be turned into hyperlinks, as they don’t lead to an internet resource, and none of them were made hyperlinks in the submitted Word file. However, the final Word document returned by ISO has them as hyperlinks. As best as we can tell, this was done (manually) by ISO editors based probably on what they saw in the PDF version of the submitted spec. Unfortunately, MS Word’s option “Save as PDF” results in these hyperlinks links being erroneously created, and there is no way to stop that from happening. Certainly, making them links was never the intention.

Question for ISO: Assuming we’re required to send a new PDF with the final Word draft, how can we ensure that no incorrect links in the PDF get applied to the final Word version? (Perhaps we need to find an alternate way to generate a PDF from Word. What tool does ISO use for this and does it handle XML namespaces correctly?)

ISO: Our treatment process does a URL check, to ensure URLs are correct/valid, and one component of this is to transform link-like text into hyperlinks. We will discuss how to approach adjusting this so that it doesn’t activate unwanted hyperlinks.

ISO: Again, the DIS word and pdf files were not checked by the ISO editor before being released for the ballot. For FDIS, I'll check and make sure that hyperlinks are not created for namespaces to be aligned with the submitted word file. Per earlier communication with Makoto, if web links can be preceded with “available at” consistently throughout the document, it would be easier for me to differentiate them from, say, namespace names.

[Q-Swan]

I see existing uses of "available at" in Part 2 (Clause 7) which should not be turned into links.

Clearly, using "Available at" in Normative References and Bibliography is not a problem. We have used "accessible as a link" in Annexes C and D. Would YC be prepared to rely on that terminology when doing her manual procedure at the end of the toolchain?