[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Version
All, >1) Version number > Should this be a number or a string? > Should there be any requirement for applications to take notice of > it (i.e. standard upgrade semantics, 1.1 extends 1.0, 2.0 is incompatible) I don't have a strong preference for either representation, but I would like it to be CONVERTIBLE to a number (i.e. NOT something like 1.2.13, which has no corresponding numerical representation) so that at least after conversion you can use comparison operators like "<" or ">" on it. > Should the version be the schema string? > The fact that Chris used the schema string is leading me to strongly >suspect that the Version attribute is actually redundant and that the XMLNS >attribute has the same function. Not being an XML guru, I'm not really competent to address this. However if there IS an existing XML structure which we can use then I would prefer doing that to introducing a new element. My base position on this is that: (1) It MUST be possible to determine the version of each SAML assertion structure (2) It SHOULD be possible to convert the version element associated with a SAML assertion into a number (3) Version identification MAY include both "major version" and "minor version" but should not distinguish at a finer granularity than "minor version" (4) Version numbers MUST be monotonically increasing with successive revisions of the spec Have I missed anything? > So far everyone is keen on the idea of a version attribute but >unless someone can say how it is to be used I think we should yank it and >rely on xmlns. If this meets the criteria above I agree it's preferable > We need some text to describe what is going on either way. Definitely --bob Bob Blakley (email: blakley@us.tivoli.com phone: +1 512 436 1564) Chief Scientist, Security, Tivoli Systems, Inc. "Hallam-Baker, Phillip" <pbaker@verisign.com> on 07/31/2001 11:54:27 AM Please respond to "Hallam-Baker, Phillip" <pbaker@verisign.com> To: "Security-Services (E-mail)" <security-services@lists.oasis-open.org> cc: Subject: Version and Namespace issues All, 1) Version number Should this be a number or a string? Should there be any requirement for applications to take notice of it (i.e. standard upgrade semantics, 1.1 extends 1.0, 2.0 is incompatible) Should the version be the schema string? The fact that Chris used the schema string is leading me to strongly suspect that the Version attribute is actually redundant and that the XMLNS attribute has the same function. So far everyone is keen on the idea of a version attribute but unless someone can say how it is to be used I think we should yank it and rely on xmlns. We need some text to describe what is going on either way. 2) Namespaces The time has come folks, we need to take out the current date that refers to the completion date of one of my direct ancestors successful corporate takeovers. I propose using the following identifiers which will resolve to the relevant docs in the repository: http://www.oasis-open.org/committees/security/docs/yyyymmdd-assertion-draftn n.xsd http://www.oasis-open.org/committees/security/docs/yyyymmdd-protocol-draftnn .xsd where yyyy, mm, dd and nn are appropriately instantiated. Final versions would be vX.Y Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC