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
<<attachment: winmail.dat>>
10 messages in org.oasis-open.lists.security-servicesRE: [security-services] Addition of m...