[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