This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 30255 - [FO31] Link to outdated document from 2004, on Character Model Normalization
Summary: [FO31] Link to outdated document from 2004, on Character Model Normalization
Status: RESOLVED INVALID
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Functions and Operators 3.1 (show other bugs)
Version: Recommendation
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-05-14 23:09 UTC by Abel Braaksma
Modified: 2018-05-27 13:39 UTC (History)
0 users

See Also:


Attachments

Description Abel Braaksma 2018-05-14 23:09:45 UTC
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.
Comment 1 Michael Kay 2018-05-14 23:36:10 UTC
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.
Comment 2 Abel Braaksma 2018-05-27 13:39:29 UTC
> 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).