OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: Naming and Structure Issues


I would suggest we separate out a set of naming issues 
from the structural issues. The naming issues (together
with the choice of a namespace URI) can be settled 
quickly and without extended debate.

Just to make my position clear, here are the proposed naming rules:

>>> 1) Construction Of Names
>>> 	All names are implicitly scoped under the 
>>specification, no element
>>> contains the specification as part of its name. Rationale - 
>>the elements
>>> will be prefixed in most applications <samp:SAMLFooBar> is redundant
>>> 
>>> 	All names are composed of words spelled out in full without
>>> abreviations with the first letter of each word capitalized 
>>including the
>>> first.
>>> 
>>> 2) Hierarchy
>>> 	The interpretation of a name should not rely on 
>>implicit knowledge
>>> of the XML hierarchy. Rather a name should inform the reader of the
>>> hierarchy. So an <AttributeAssertion> is an extension of an 
>><Assertion>.
>>> The head element name is written after the adjective describing the
>>> element that extends it.
>>> 
>>> 	Where an element contains sub elements the sub elements 
>>only take
>>> the name of the parent if ambiguity might otherwise arise
>>> 
>>> 3) Types, Abstract types etc.
>>> 	A type name ends with the word Type, the name of an 
>>abstract type
>>> ends with the words AbstractType
>>> Where an element is declared of a particular type the 
>>default name of the
>>> element is that of the type with

- prateek


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC