For the benefit of non-W3C-insiders, what are you trying to tell us here Norm? The CR that was just released uses xml:id, not xmlid, but I'm guessing that's not what we're going to see in the REC after all.

The W3C needs to get its act together when to comes to evolving their various specs. I had a rant pending about the fact that another addition was being made to the XML namespace without a consideration for the downstream breakage but it seems the W3C has come to their senses. Instead of whining about this, the W3C crowd should figure out what their versioning and extensibility story is going to be instead of pretending they can ignore backwards compatibility when deploying specs.

Thanks Norm for writing this funny story. Exactly my feeling. C14N is already broken for xml:base (since it does not inherit), so let's fix it.

The longer the spell, the more uncertain the results.

Hi Michael,

The W3C Quality Assurance Working Group is working on that. It's indeed very important to not only produce a good technical specification, but also to spend time on the normative reference analysis. How each specification will impact on the specification, the WG is producing by their technical requirements or their own conformance model.

The Good Practice is Do systematic reviews of normative references and their implications.

http://www.w3.org/TR/qaframe-spec/#ref-define-practice

If such analysis was made by WGs when they create specifications, that would be a way of controlling the risks of incompatible dependencies.

But we also have to accept that with the quality process (Publication rules, requirements of interoperability and implementations, QA, etc.) add a bit of time to the whole thing. Some W3C Members think that there is not enough process, some think that there is too much. It's always a question of reaching the consensus.

Producing a good specification takes time at many levels. It's not an easy task.

I'd like to think that xml:id is solving a real problem and that not having xml:id (or xmlid) would leave that problem unsolved (and therefore be a bad thing) but I'm having a real problem constructing any currently working examples of breakage.

Currently I serve a lot of xml files, and I use a lot of fragment itentifiers pointing in to them.

http://www.w3.org/TR/MathML2/chapter1.xml#id.1.2.2

for example.

that file has an id attribute of id.1.2.2 that is of type ID, but it would have made no difference if it was of type CDATA the link would still have worked. I always style the served XML with XSL (see your recent essay on CSS:-) and if you do that, the identifiers that matter to the fragment syntax are (whatever any spec says) the identifiers in the generated (X)HTML not the identfiers in the XML file. Being able to reliably refer to ids in the XML file would be useful for some machine to machine translation scenarios, and sematic web type statements but in the use case in your "story" linking into human oriented documents, they just don't seem to be relevant at all

That said the current storm over xml:id just seems really strange. Surely it is clear that the sets of names refered to by a namespace are all the same (names matching NCName) so all this talk of adding names to namespaces is bogus. It seems that teh people who wanted the original namespace spec to say that a namespace was defined by (and uniquely associated with) a schema will just never accept that it does not say that, and we have the 3-namespaces for html debate every other year.