W3C home > Mailing lists > Public > public-qt-comments@w3.org > September 2005

[Bug 2305] stable fragment ids in specifications (editorial)

From: <bugzilla@wiggum.w3.org>
Date: Mon, 26 Sep 2005 12:41:52 +0000
To: public-qt-comments@w3.org
Cc:
Message-Id: <E1EJsIq-0004dK-40@wiggum.w3.org>

http://www.w3.org/Bugs/Public/show_bug.cgi?id=2305

           Summary: stable fragment ids in specifications (editorial)
           Product: XPath / XQuery / XSLT
           Version: Last Call drafts
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XQuery
        AssignedTo: chamberl@almaden.ibm.com
        ReportedBy: davidc@nag.co.uk
         QAContact: public-qt-comments@w3.org


I'm raising this issue on XQuery, but it probably relates to all documents, as
they use the same build process, I think.
Most sections use a stable fragment identifier but some use one that looks like
the result of XSLT generate-id()

For example appendix H (Glossary) may be referenced as
http://www.w3.org/TR/xquery/#id-glossary
but appendix I (Example applications) may be referenced (today) as
http://www.w3.org/TR/xquery/#N1815A


Apart from not looking so nice, if these IDs are automatically generated it
means that they are _not_ stable and so the above URI reference will _break_
at the next draft as the copy in the undated URI is updated "in place".

there are several other examples, as easily seen by hovering over the table of
contents and watching the status line.

Presumably this could easily be fixed by giving the sections ids in the xmlspec
source or (as I did in MathML) modifying the stylesheets to use a more stable
generated id (for example based on the sction number).

David
Received on Monday, 26 September 2005 12:43:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:08 UTC