Xml Mailing List: RE: It's input time guys.

[Mark Jones (mjones]

Dave,

I'd started going through the draft in greater detail with the intention of
providing the validity constraints and some re-wording suggestions. Due to
other commitments, I've only got up to "enums" but I will get through the
rest before Friday. Sounds like that may be too late for you but I'm sending
what I've got.

BTW, I am convinced that the subject of XML Schema will come up when this
draft is published so don't delete that DiameterSchema.xsd from CVS just yet
:)

---

General suggestions:

+ Replace "Container" with "Element" throughout to be consistent with the
W3C terminology.
+ Modify the "name" attribute on the Vendor element to be #REQUIRED. Don't
see why anyone would need to define an anonymous vendor.
+ Modify the Attribute|Classification table to contain columns for:
        Attribute: name
        Presence: Required | Optional
        Constraints: None | UniqueKey | Reference
        Values: Permitted values and defaults
+ Remove the element name from the sub-section title for attributes, i.e.
make it '"id" Attribute' instead of 'vendor attribute "id"'.
+ Remove the CVS revision log from the DTD.

Sorry, I'm not too familiar with nroff so I'm sending you the raw text for
expediency.

----

3.1 Vendor Element

The Vendor element defines a vendor by a name and associated IANA assigned
"SMI Network Management Private Enterprise Codes" [4].

3.1.1 "id" Attribute

  The "id" attribute is the vendor code assigned by IANA [4]. The "id" MUST
be unique across all Vendor element definitions although this constraint can
not be enforced by the DTD.

3.1.2 "name" Attribute

   The "name" attribute is some text describing the vendor. Although the
Diameter protocol only requires the vendor code for encoding and decoding
messages, the vendor name MAY be used in trace utilities to facilitate
debugging.

3.2 Type Definition Element

   The Type Definition container defines a valid Diameter data type. Every
attribute value pair definition MUST refer to a type definition. The most
common use of this container is to indicate which base type a derived type
derives from.  This helps the server to know how (and if) an AVP should be
displayed.

3.2.1 "type-name" Attribute

   The attribute, "type-name" contains an ascii representation of the type.
This attribute is of type ID allowing the DTD to enforce its uniqueness
across all typedefn elements. This also permits other attributes of type
IDREF to refer to the type-name value and have the DTD enforce the
referential integrity.

3.2.2 "type-parent" Attribute

   The "type-parent" attribute is required for all derived types.  This
attribute is of type IDREF ensuring that its value MUST correspond to the
value of a type-name attribute of a pre-defined typedefn element.

3.2.3 "description" Attribute

   The "description" attribute is an optional attribute describing the
   type.  Typically a human readable description of what the type is
   used for would be included here.

---


Regards,
       Mark