Xml Mailing List: Contributions for draft

[Mark Jones (mjones]

Dave,

I think we should consider pulling the "base", "application" and "command"
sections forward in the document so that the order matches their appearance
in the XML file. What do you think?
E.g.
      3.0  Dictionary Layout
         3.1  Vendor Element
         3.2  Base Element
         3.3  Application Element
         3.4  Command Element
         3.5  AVP Rule Element
         3.6  Type Definition Element
         3.7  Attribute Value Pair Element
         3.8  Type Element
         3.9  Grouped AVPs Element
         3.10 Enumerated Element

I also noticed that the "type" element section is missing from the draft.

---
(Section numbers refer to existing draft)

3.0 Dictionary Layout

The root or top-level element of a Diameter dictionary is the "dictionary"
element. The dictionary element contains zero or more "vendor" elements, the
"base" element and zero or more "application" elements.

The top-level XML file containing the "dictionary" element SHOULD be named
"dictionary.xml". Each "application" element SHOULD be defined in a separate
XML file and referenced from the top-level XML file using an external entity
declaration.

3.3  Enumerated Types Element

The enum element defines a name to value mapping for use in encoding and
decoding   AVPs of type Unsigned32.

(together with your example, I think this is all we need here.)

3.4  Attribute Value Pairs

The avp element completely defines one Attribute Value Pair and is the most
frequently used element in the dictionary. The avp element contains either a
type element, or a grouped element, and zero or more enum elements together
with attributes that completely define the AVP including format and flags.

3.4.3 "code" Attribute

The "code" attribute defines the integer value used to encode the AVP for
transmission on the network.

3.5  Grouped AVPs

The grouped element is used define an AVP which encapsulates a sequence of
AVPs together as a single payload.

3.6  AVP Rules

The requestrules and answerrules elements define the placement of key AVPs
within request and answer commands respectively. These elements may be used
to perform syntax checking at the protocol layer.

3.6.1 "name" Attribute

This rule applies to the previously defined AVP with the matching "name"
attribute.

3.x Base Protocol Element

The base element defines the commands, data types and AVPs that are part of
the Diameter Base Protocol [1].

3.x Application Element

One of the ways in which the Diameter protocol can be extended is through
the addition of new applications. The application element defines the new
Commands, Types or AVPs needed to support a new Diameter application. It may
also reference elements defined in the base protocol.

3.x Type Element

The type element defines the data type of the AVP in which it appears. This
element MUST appear in all non-grouped AVP definitions.

3.x.1 "type-name" attribute

The "type-name" attribute contains the data type name. This attribute is of
type IDREF and MUST refer to the "type-name" value of a previously defined
"typedefn" element.

---

Regards,
       Mark