> After seeing the back-and-forth, I agree with Scott. Even if we made it
> OPTIONAL/RECOMMENDED and in practice required it for doing correlation
> and such, we'd confuse the heck out of everybody and everything by
> allowing other globally scoped ID attributes. (And he's right about
> xml:* being disallowed until XML officially recognizes it and parsers
> are updated.)
Well, I kind of liked the 2.0 -> 2.1 idea, where we make ID optional in the
schema, but mandatory in prose for 2.0, and then switch to xml:id in a 2.1
revision.
Reason being this isn't like with 1.0 -> 1.1, where we made 1.0 messages
invalid in 1.1. I think it's reasonable to consider giving up forward
compatibility with 2.1 to get to the xml:id state of nirvana quicker.
This is all assuming that xml:id is on some sort of track to get done and
implemented quickly. Otherwise, forget it.
> Hmm, maybe we shouldn't add these wildcards after all... We did say
> that we need a use case for them.
My use case is just that I want people that might want to add an attribute
for some reason to not have to extend the schema and add a new derived type
for something so trivial.
-- Scott
