Bugzilla – Full Text Bug Listing
|Summary:||SPEC - Id uniqueness is incorrect|
Description mminella 2013-03-11 22:31:58 UTC
Section 13.2 states that the id attribute must be unique within the containment scope. Two issues with this: 1. In order for an XML document to be valid, id must be unique within the document. If we want to allow duplicates, we need to use something else (name perhaps). 2. Is there a compelling reason to allow the duplication of ids at all? I would recommend enforcing that the document be a valid XML document and that ids be unique within the document.
Comment 1 ScottKurz 2013-03-12 03:15:19 UTC
These are not xs:id types, so we shouldn't have that restriction. As mentioned in other contexts, we only use xs:string since we don't have detailed rules about what values can vs. cannot be subject to property substitution.
Comment 2 mminella 2013-03-12 16:16:24 UTC
In that case, is there a reason why we wouldn't want to use xs:id types? It's more clear from a user's perspective and I don't see any issues with requiring the ids to be unique across the document...
Comment 3 ScottKurz 2013-03-12 17:20:18 UTC
One reason is indeed this property substitution issue. By the time we'd apply the identity rule in xs:id, the XML has already been parsed... so we've lost the most obvious chance to apply it.
Comment 4 cvignola 2013-03-12 17:51:37 UTC
The other reason to not require all ids be unique across a job is to avoid inheritance collisions - e.g. a job that inherits 2 flows, where each flow happens to use the same step id.
Comment 5 mminella 2013-03-12 18:14:08 UTC
I don't follow you with regards to Comment 3. With regards to Comment 4, there is nothing stopping the developer from choosing a different name for each of those two steps within the same document. For example, flow1.step1 vs flow2.step1. I am asking this namely due to the way most developers who deal with XML view the attribute id. If we aren't going to honor what id means in most XML documents, we should name it something else (name perhaps).
Comment 6 ScottKurz 2013-03-13 03:55:00 UTC
Michael, I think you're right and I let this very unlikely use case of a substitutible id influence my argument. You being OK with needing "flow1.step1" and "flow2.step1" in that case removes the final possible objection. Talked to Chris and we're updating to xs:ID ... for PFD 1.7 I'd assume...
Comment 7 cvignola 2013-03-16 20:41:20 UTC
Yes, coming in PFD v1.7.