[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] Addition of more wildcarding
Making ID optional in the schema could allow for using other xsd:ID based identifiers, like wsu:ID. We could "STRONGLY RECOMMEND" the use of the SAML-defined IDs in prose, but allow these others. -- Steve Anderson OpenNetwork -----Original Message----- From: Scott Cantor [mailto:firstname.lastname@example.org] Sent: Friday, August 06, 2004 2:41 PM To: 'Greg Whitehead' Cc: 'SAML'; 'Eve L. Maler' Subject: RE: [security-services] Addition of more wildcarding > Actually, what's the problem with making ID a SHOULD instead of MUST? Well, mainly the fact that we do things like request/response correlation, and so forth. But maybe we shouldn't dismiss out of hand some kind of built-in migration to xml:id by making ID optional. Is this worth trying? The tricky bit is that even though xml:id would be schema-legal for all 2.0 implementations, it wouldn't be "parser-legal". Anybody using an actual XML parser (as opposed to hand-parsing) would get errors until the parser supported xml:id. At least I think so, xml: is supposed to be a reserved namespace prefix that you can't use unless it knows about the attribute. It seems like it would be messy to have people generating "compliant" SAML 2.0 that couldn't be accepted by all 2.0 products, no? I suppose it could be done with a 2.1 spec that was backward-compatible, but not forward-compatible. 2.1 products would handle 2.0 without much incident, but 2.0 products would choke on 2.1 messages, since they would carry the xml:id instead. -- Scott To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/security-services/members/leave_workgroup.php.