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 29857 - [FO31] Uniqueness scope for generate-id()
Summary: [FO31] Uniqueness scope for generate-id()
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Functions and Operators 3.1 (show other bugs)
Version: Candidate Recommendation
Hardware: PC All
: 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: 2016-09-22 08:04 UTC by Michael Kay
Modified: 2016-12-16 19:55 UTC (History)
0 users

See Also:


Attachments

Description Michael Kay 2016-09-22 08:04:06 UTC
We say under generate-id():

An implementation is under no obligation to generate the same identifiers each time a document is transformed or queried.

This is a very informal way of saying that the uniqueness rule is scoped to a single execution scope. It casually implies that there is a concept of node identity ("a document") that transcends execution scope, which formally speaking is not the case (although XQuery Update might suggest otherwise). And it raises questions about situations where a transformation or query can involve multiple execution scopes, for example when fn:transform() is called, or when XSLT static expressions are used.

I propose the following slightly more formal statement. After

"In other cases, the function returns a string that uniquely identifies a given node."

add

"More formally, it is guaranteed that within a single *execution scope*, codepoint-equal(generate-id($N), generate-id($M)) is true if and only if ($M is $N) is true." 

and move the sentence

"An implementation is under no obligation to generate the same identifiers each time a document is transformed or queried."

to the (non-normative) notes, since its meaning depends on informal notions of identity.
Comment 1 Michael Kay 2016-09-22 08:11:49 UTC
Anticipating WG approval, I have applied the suggested changes to the spec.
Comment 2 Michael Kay 2016-09-27 21:02:48 UTC
The WG agreed the changes, which are already in the spec.