Subject: [IPTEL] CPL DTD and switches

From: Daniel Amyot <[email-masked]>
Date: Fri, 14 Dec 2001 16:48:58 -0500

Hello,

now that the IPTEL list server is back, here is a comment related to the
latest CPL Document Type Definition. In draft 05, the switch elements have the
following form (I am using the address-switch here, but the problem is the
same for time, priotiry, language, and string switches):

<!ELEMENT address-switch ( (address|not-present)*, otherwise? ) >

It is said that all switches can have an ’otherwise’ output and a
'not-present' output. However, the expression above creates a few problems:

1) multiple <not-present> items:

<address-switch field="origin" subfield="host">
  <not-present>
    <sub ref="cellphone" />
  </not-present>
  <not-present>
    <sub ref="voicemail" />
  </not-present>
</address-switch>

2) A standalone <otherwise>

<address-switch field="origin" subfield="host">
  <otherwise>
    <sub ref="voicemail" />
  </otherwise>
</address-switch>

3) An empty switch

<address-switch field="origin" subfield="host">
</address-switch>

I can see how one can have a <not-present> alone or accompanied by an
<otherwise> (especially if the <authorisation> switch makes it to the
standard), but having multiple <not-present>, a standalone <otherwise>, or en
empty switch do not make much sense to me. What could be a better alternative
is something of the following form (thanks to Jacques Sincennes' suggestion):

<!ELEMENT address-switch ( (address+|(address*,not-present)), otherwise? ) >

This would ensure that:
1) there would be at most one <not-present>
2) <otherwise> would be preceeded by at least one <address> or one
<not-present>
3) the switch would contain at least one <address> or one <not-present>

This form could be used for the other switches as well.

Also, it would be nice to have examples in the standard that male use of the
<not-present>.

Regards,

Daniel
_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel

---

From: Jonathan Lennox <[email-masked]>
Date: Fri, 14 Dec 2001 18:19:30 -0500

> 1) multiple <not-present> items:

This is illegal.  However, I didn't want to dictate any ordering of
<not-present> items with respect to other switch output nodes.  ('The output
"not-present", which MAY occur anywhere in the list of outputs....') Thus,
there's no (pretty) way to state this restriction in DTD syntax.  (I feel
that any regex where you have to specify "address*" twice is fairly ugly,
since there's not actually any semantic difference between the two times the
term appears.)

Remeber this paragraph from the start of Appendix C:

   Note that compliance with this DTD is not a sufficient condition for
   correctness of a CPL script, as many of the conditions described in this
   specification are not expressible in DTD syntax.

I should maybe add "or not expressible conveniently" there.

> 2) A standalone <otherwise>

These aren't useful, but they're clearly well-defined, and I don't see any
reason to forbid them.  I actually changed the Draft-05 DTD syntax to
*allow* these possibilities.  Many (if not most) CPL scripts are going to be
machine-generated, and it's a lot cleaner for generating utilities not to
have to special-case the degenerate case of switches.  (This will allow a
generating utility to create a CPL script from a template, for instance.)  I
don't think this imposes any burden to speak of on a CPL server. 

> What could be a better alternative

In addition to failing my "ugly" criterion above, this also constrains the
position of <not-present> to follow all the <address> nodes, contrary to the
text of the spec.

> Also, it would be nice to have examples in the standard that male use of the

Yes, I agree.  If you'd like to write one up, I'll be happy to stick it in
the spec for final IESG submission.  (This applies for any CPL features
people think are inadequately covered in the examples section.)

Thanks for your comments!

-- 
Jonathan Lennox
[email-masked]

---

From: "Richard H. Gumpertz" <[email-masked]>
Date: Fri, 14 Dec 2001 16:59:02 -0600

Comments in line, marked [RHG].

><address-switch field="origin" subfield="host">

[RHG] Indeed, the syntax allows multiple <not-present> items BUT the associated text then prohibits them.  Your suggested change to the syntax is probably a good idea, but with some modifications (see below).  I have always been bothered by having syntax rules that required modification by the text.

><address-switch field="origin" subfield="host">

[RHG] What is wrong with a standalone <otherwise>?  The meaning is clear: always use this output.  Note that this might result from mechanically-generated CPL.

><address-switch field="origin" subfield="host">

[RHG] What is wrong with an empty switch?  The meaning is clear: always use the "default behavior" described in section 11.  Again, this might result from mechanically-generated CPL.

>3) the switch would contain at least one <address> or one <not-present>

[RHG] For your case, where you want at least one address or not-present, the following would be more correct:
        <!ELEMENT address-switch ( (address+|(address*,not-present,address*)), otherwise? ) >
This allows <address> to follow <not-present> which your syntax does not.

[RHG] If, on the other hand, we accept empty and <otherwise>-only switches, then this can be simplified to:
        <!ELEMENT address-switch ( address*, not-present?, address*, otherwise? ) >
[RHG] I hereby propose this latter syntax.

[RHG] An aside for the purists who want an unambiguous syntax, this could also be expressed as:
        <!ELEMENT address-switch ( address*, (not-present, address*)?, otherwise? ) >

>This form could be used for the other switches as well.

[RHG] Agreed, all switches should use the same general syntax form.

>Also, it would be nice to have examples in the standard that male use of the

[RHG] To be a bit snide, but, more importantly, also fair to the authors: why don't you propose a specific example for possible inclusion?  If nothing else, you might include something that they might not think of...

>Daniel

[RHG] I very much like your idea of getting the syntax to stand on its own. Thanks!

                Rick
--
  Richard H. Gumpertz, Ph.D.
  Raviant Networks, Inc.
  office: +1 (913) 266-5137
  mobile: +1 (913) 484-8777

---

From: Jacques Sincennes <[email-masked]>
Date: Fri, 14 Dec 2001 19:24:35 -0500

Hello,

Comments in line, marked [JS].

> [RHG] What is wrong with a standalone <otherwise>?  The meaning is clear: always use this output.  Note that this might result from mechanically-generated CPL.

A standalone <otherwise> is not sound.  Since there is no initial
condition to begin with, how could there be an otherwise?  This is
demonstrated by the fact that:

would be semantically the same as:

and, for that matter, identical to:

<sub ref="voicemail" />

> [RHG] What is wrong with an empty switch?  The meaning is clear: always use the "default behavior" described in section 11.  Again, this might result from mechanically-generated CPL.

What is right about a completely useless statement?  The
mechanically-generated CPL could be fixed by removing that address-switch
node altogether.

It's pretty strange to define unsound syntax for sole purpose of
accomodating some ill-conceived CPL generator.

> This allows <address> to follow <not-present> which your syntax does not.

Given that the location of <otherwise> is already fixed, why not also fix
the location of <not-present>?  The benefits of having a more precise
syntax appears to overweight the capability of putting <not-present>
at any given location.

> [RHG] To be a bit snide, but, more importantly, also fair to the authors: why don't you propose a specific example for possible inclusion?  If nothing else, you might include something that they mi…

With spammers in mind, here's one:

<address-switch field="authentication">
  <not-present>
    <sub ref="block" />
  </not-present>
</address-switch>

> [RHG] I very much like your idea of getting the syntax to stand on its own. Thanks!

Best regards,

Jacques
-- 
Jacques Sincennes, System Analyst   | /  email:  [email-masked]
LOTOS Group, University of Ottawa   | \  phone:  +1 613 562 5800 x6724
MCD #406, Ottawa, Ontario, Canada  \| /  fax:    +1 613 562 5187
_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel

---

From: "Richard H. Gumpertz" <[email-masked]>
Date: Fri, 14 Dec 2001 19:57:45 -0600

Further comments in-line, marked [RHG2]:

>and, for that matter, identical to:

[RHG2] The C language allows switch statements with just a "default:" case; this is identical except for semantics that might be tied to the English meaning of the otherwise.

>accomodating some ill-conceived CPL generator.

[RHG2] Then why haven't you complained about other empty nodes?  Why should switches be any different than any other tags?

>syntax appears to overweight the capability of putting <not-present>

[RHG2] The location of <otherwise> allows a simple-minded script-processor to process the <otherwise> correctly (and without surprise to the script-writer) without looking forward past the <otherwise>.  There is no such requirement for <not-found>: it can be processed first, last, or anywhere else.

---

From: Jacques Sincennes <[email-masked]>
Date: Fri, 14 Dec 2001 22:30:41 -0500

Hello,

Comments in-line.  *This time*, I've marked them [JS]

> [RHG2] The C language allows switch statements with just a "default:" case; this is identical except for semantics that might be tied to the English meaning of the otherwise.

[JS] My point exactly!  The switch statement with just a "default:" serves no purpose but to obfuscate the code.  The "default body" will be executed each and every time, regardless of the expression it pretends switching upon:  the "default body" does NOT require a switch statement to begin with!  Note that I make no claim on the sanity of the C language.

> [RHG2] Then why haven't you complained about other empty nodes?  Why should switches be any different than any other tags?

[JS] Because empty switches bear no meaning, contrary to other empty nodes.  The address-switch without an address makes no sense; nor does the time-switch without a time specification, nor a string-switch without a string.

[JS] <not-present> is an exception mechanism that addresses the case where the condition cannot be evaluated.  This provides for a 'valid condition' that can be used on its own or in conjuction with other 'conditions' (e.g. specific addresses, for address-switches).

[JS] To illustrate this using the C language, an empty switch is similar to an "if" statement withtout a condition; a switch with just the <otherwise> part is similar to an "if-then-else", without condition nor "then body".  Even if such a construct was accepted by the C language, that wouldn't make it any more right.

> [RHG2] The location of <otherwise> allows a simple-minded script-processor to process the <otherwise> correctly (and without surprise to the script-writer) without looking forward past the <otherwi…

[JS] I did not claim that there was a requirement to put <not-found> anywhere specific.  I merely suggested that it might as well have a speficic position.  But in the light of your reply, there is a legitimate reason to request to have it first.

[JS] For the sake of a similar simple-minded script-processor as the one mentionned above, it should prove necessary to have the <not-found> statement come in first.  In instances where the data is indeed not found, having <not-found> as the first condition processed will be necessary for the simple-minded script-processor to avoid "evaluation errors" (e.g. by comparing addresses which are not there).  On top of that, the syntax will be consistent in both the DTD and the body text.

[JS] NB:  when you say "processed last", I assume you mean "last before <otherwise>".

Best regards,

Jacques

---

From: "Richard H. Gumpertz" <[email-masked]>
Date: Sat, 15 Dec 2001 05:53:47 -0600

Unless you make the <not-found> both first and MANDATORY, the simple-minded script processor will still have to avoid "evaluation errors" because it may encounter a <address> without a preceding <not-found>.

                Rick