[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Additional suggestions for naming changes
This completes an action item I took in the May 11 telecon. I went for aesthetics as much as brevity and consistency in the following list, using cues from speaking and whiteboard-writing patterns. Since choosing to abbreviate means that you have to apply *some* value judgment (as opposed to simply spelling out the name as the Deity intended :-), this was necessary. (Having read through the schemas closely, I have to say that I like the overall effect of the truncation changes we made last week. BTW, we'll be uploading those changes Real Soon Now... Doing a little bit more in this direction could be good.) I'm not sure I like all of the following, but I thought I would list all the plausible possibilities and see what people think. Here's a summary of the following sections: Qualifier -> Qual Reference -> Ref Statement -> Stmt Confirmation -> Conf Condition -> (null) Reauthenticate -> Reauthn Attribute -> Attrib or Att Service -> Svc Assertion -> Assn Qualifier -> Qual I give this one a C grade. It doesn't look that good, and people don't really elide the "ifier" when they talk. I suppose "Qualif" is an option, but it doesn't save that much. In saml:BaseIDAbstractType: s/NameQualifier/NameQual/ s/SPNameQualifier/SPNameQual/ In samlp:NameIDPolicyType: s/SPNameQualifier/SPNameQual/ Reference -> Ref I give this one an A grade. People do talk about "refs", and the names in which Reference appears are long enough already. s/saml:AssertionIDReference/saml:AssertionIDRef/ s/saml:AssertionURIReference/AssertionURIRef/ Statement -> Stmt I give this one an F grade, so I'm not going to bother listing all the things it changes. (I do frequently use this abbreviation when writing, to be honest.) If people are interested, I can list all the locations. Confirmation -> Conf I give this one a C grade. The "nf" combination is tough and unnatural to say, even though the word gets shortened considerably. Alternatively we could shorten Confirmation to Confirm, but then it sounds like a verb, which is not a naming pattern we've used outside of the protocols. s/saml:SubjectConfirmation/saml:SubjectConf/ s/saml:SubjectConfirmationType/saml:SubjectConfType/ s/saml:SubjectConfirmationData/SubjectConfData/ Condition -> (null) I give this one an A- grade. The names are perfectly evocative without Condition -- words like "restriction" and "use" describe conditions -- and the elements are still of type Condition. The only ding against it is that it breaks our previous naming pattern. s/saml:AudienceRestrictionCondition/saml:AudienceRestriction/ s/saml:AudienceRestrictionConditionType/saml:AudienceRestrictionT ype/ s/saml:OneTimeUseConditionType/saml:OneTimeUseType/ s/saml:ProxyRestrictionConditionType/saml:ProxyRestrictionType/ (saml:Condition remains the same) Reauthenticate -> Reauthn I give this one an A- grade. I'm tempted to suggest just Reauth without the "n", since people might actually say that (and not confuse it with "reauthorize"?), but that really does go against the pattern we've just started adopting. In saml:StatementAbstractType: s/ReauthenticateOnOrAfter/ReauthnOnOrAfter/ Attribute -> Attrib or Att I'm not sure what to think of this one. It would affect a lot of things; I haven't listed them all yet. I frequently truncate them when writing them out, with "attrib" being more identifiable; I would tend to say "att" and not "attrib" when speaking, but would rarely say either one. Note that we've now truncated its two companions, Authn and AuthzDecision. Service -> Svc I give this one a B grade. It's all consonants and therefore ugly, but is relatively common. In samlp:RequestAbstractType: s/AssertionConsumerServiceID/AssertionConsumerSvcID/ s/AssertionConsumerServiceURL/AssertionConsumerSvcURL/ Assertion -> Assn (Notice I didn't suggest "Ass." :-) I don't particularly like this one; I frequently write it in truncated form, but since assertions are so essential to the SAML model, I'm reluctant to take away its "dignity". I haven't listed all the places affected. Eve -- Eve Maler +1 781 442 3190 Sun Microsystems cell +1 781 354 9441 Web Products, Technologies, and Standards eve.maler @ sun.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]