Xml Mailing List: RE: Have you guys had a chance to review Yoshihiro's comments?

[Mark Jones (mjones]

Personally I have no intention of using an XML parser to validate my
commands due to the performance hit. That said, if we are going to
describe the diameter message at all in the DTD, we should try to get as
close to the ABNF as a DTD will permit.

Dave suggested the following and I agree that this does allow one to
fully describe a command in XML:

   <!ELEMENT avprule EMPTY>
      <!ATTLIST avprule
         name #IDREF #REQUIRED
         fixed (yes|no) "no"
         required (yes|no) "no"
         optional (yes|no) "yes">

If I've understood correctly, Yoshihiro's point is that this also allows
one to define a command which does not meet the ABNF for commands:

   diameter-message = header  [ *fixed] [ *required] [ *optional] [
*fixed]

For example, it allows me to define a command where an optional AVP
appears before a required AVP.

I don't have a problem with the suggested:

   <!ELEMENT requestrules (fixed* required* optional* fixed*)>

but we'd still need a way to express the arbitrary AVP: '* [ AVP ]'.
Mapping use of it onto the diameter message ABNF, the arbitrary AVP
could only appear in the optional section of a message, right?

So we could handle this with an attribute on the
requestrules/answerrules elements:

   <!ELEMENT requestrules (fixed* required* optional* fixed*)>
      <!ATTLIST requestrules allowArbitrary (yes | no) "no">

However, I am concerned that we are creating an expectation that you
could write a dictionary in XML, run it though a validating parser and
if is passes, the dictionary is good. The simple fact is that a DTD does
NOT allow us to enforce all the constraints required to guarantee a sane
dictionary. I think we should point this out in the draft making it
clear that this is not a shortcoming in our DTD but rather in the
mechanisms at our disposal when writing a DTD.

Regards,
       Mark