| Re: Why? | <– Date –> <– Thread –> |
|
From: David Frascone (dave |
|
| Date: 13 Dec 2001 16:42:35 -0000 | |
I'm still working on it between meetings, but here is the direction the DTD
is going so far:
# Is there a way to say that either of these can be present, but only once?
<!ELEMENT command (requestrules*, answerrules*)>
<!ELEMENT requestrules (avprule+)>
<!ATTLIST requestrules EMPTY>
<!ELEMENT answerrules (avprule+)>
<!ATTLIST answerrules EMPTY>
<!ELEMENT avprule EMPTY>
<!ATTLIST avprule
name IDREF #REQUIRED
rule (first | last | required | forbidden) #REQUIRED
>
Note, I just modified the above, so there might be syntatical errors, but
you should see what I'm thinking. I took Mark's alternative approach.
Also, I modified my suggestions in the many previous e-mails in October to
only have four possible rules: first, last, required, or forbidden. If an
AVP is *not* listed, then it may be optionally included.
I know this will not completely model the BNF, but I think it is good enough
for transport level message validation. Any more complex validation will have
to be done by the particular application.
Comments?
On Wednesday, 12 Dec 2001, Mark Jones wrote:
> Dave,
>
> Mea culpa. The reason I split the commands into 'request' and 'answer' was
> the expectation that we would soon be expanding the <command> element to
> include sub-elements to define the mandatory/optional/fixed avps each
> contained.
>
> An alternative would be:
>
> <command name="Ping" code="511" vendor-id="42">
> <request>
> -- avps in request
> </request>
> <answer>
> -- avps in answer
> </answer>
> </command>
>
> Either way, we need somewhere to hang the command definition and requests do
> differ from answers in their avp content.
>
> (BTW, the recent email silence is due to an internal re-org which has pushed
> me away from any 'official' Diameter work for the moment.)
>
> Regards,
> Mark
>
> _______________________________________________
> Xml mailing list
> Xml [at] mail.frascone.com
> http://mail.frascone.com/mailman/listinfo/xml
Results generated by Tiger Technologies using MHonArc.