[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
I think that this issue has not nearly been debated enough to vote upon - I accept personal responsibility for my extreme busyness. It seems that issue #1 says the design for SAML means it's a set of verbs and nouns and it has an <xsd:any> element that allows extensions, and issue #2 says that an external vocubalary has <xsd:any> element that allows (SAML) extensions. I'm really unsure how to vote on these. I can argue for and against different combinations. The tricky part is that issue #1 means that we have to define verbs (the outer construct), and issue #2 says that we have to define nouns (something that can be embedded inside a different vocabularies verbs). Issue #1 instance <envelope> <body> <updateSession> <SAMLAssertions> </SAMLAssertions> <Extensions></Extensions> </updateSession> <body> <envelope> Issue #2 instance <envelope><body> <sendStuff> <myStuff></myStuff> <saml:SAMLAssertions> </saml:SAMLAssertions> </sendStuff> </body></envelope> In case #1, I see that the first piece of software that recieves a SAML request will be a SAML compliant piece of software. It will then have other parties registered for various pieces of the software. Whereas in case #2, the first piece of software will be generic and have a pipeline of flow, ie first step: validate saml components; second step: dispatch to myStuff handler. It seems unclear to me which way an xml processor will operate on the data. I really think we should have more of an idea of how the software will use this and flesh out our domain model and interactions before voting on this. But that might just be the analyst in me. Dave Orchard XML Architect Jamcracker Inc., 19000 Homestead Dr., Cupertino, CA 95014 p: 408.864.5118 m: 604.908.8425 f: 408.725.4310 www.jamcracker.com - Sounds like a job for Jamcracker.
Powered by eList eXpress LLC