This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Section 5.4.6 (https://www.w3.org/TR/xpath-functions-31/#func-normalize-unicode) on unicode normalization mentions "FULLY-NORMALIZED" and references a W3C Draft Note from 2004. It also says that it "did not progress beyond draft status". I think this is only partially correct. The mentioned draft has significantly progressed since and is in active development. The current location is https://www.w3.org/TR/charmod-norm/. While it is still WD, the statement in the spec sounds definitive. I think it is better to be conservative and mention something like "at the time of publication of this REC ...". My suggestion would be to update the reference to the canonical link and suggest readers to follow the most recent version (similar to what we do with other references). There's one caveat with this change, though: the i18n Working Group seems to have removed "FULLY-NORMALIZED" from the more recent WD. Perhaps we should say something along those lines or even deprecate it.
The reference to a draft here is entirely deliberate, and the specification explains why it is doing so: it's stating that the motivation for a feature comes from a draft spec that wasn't pursued, and therefore the normative spec is within F+O itself. There is no value in supplying a link a later version of charmod, since the title, content, and scope of the charmod spec has changed out of all recognition from the draft that we are referring to, and the current version no longer sheds any useful light on the meaning or rationale for FULLY-NORMALIZED. I don't think there is any value in pursuing this kind of fine-tuning of the spec at this stage. It is not going to help implementors produce interoperable implementations, and it is not going to help users write correct queries and stylesheets. What is written, is written. The time for editorial improvements is long over.
> since the title, content, and scope of the charmod spec has changed out of > all recognition from the draft that we are referring to, and the current > version no longer sheds any useful light on the meaning or rationale for > FULLY-NORMALIZED. Exactly. I guess I was just too used to always pursue the latest version of any spec we reference, but indeed I spent quite some time trying to find the FULLY-NORMALIZED newest spec. I shouldn't have ;). > It is not going to help implementors produce interoperable implementations, > and it is not going to help users write correct queries and stylesheets. I see that now, thanks. I didn't understand it was intentional, just felt very odd to reference something so out of date. But since it was entirely deliberate, I'll close this as by design (which is not a resolution BugZilla has, so I'll go with INVALID).