Subject: [Iptel] 'time' element in XML schema for CPL

From: Xiaotao Wu <[email-masked]>
Date: Wed, 12 Mar 2003 10:33:42 -0500 (EST)

Hi, all,

I am trying to define XML schema for CPL since XML schema has many
advantages over XML DTD. However, there are some difficulties in defining
the 'time' element in 'time-swtich'.

CPL follows the iCalendar standard (RFC 2445) for time definition. There
is an XML definition (an IETF draft) for iCalendar, however, that's also
based on XML DTD. XML Schema provides several data types for time, such as
'xs:dateTime', 'xs:time'.

I have to say, the time defined in CPL and iCalendar is more powerful
than that defined in XML schema. However, since we are using XML
schema, we may need to have a format with using the XML Schema pre-defined
data types. This may cause backward compatibility problem with original
CPL standard.

Several changes may needd for defining the 'time' element. They are listed
as below:

   1) Use space delimited list. XML Schema only support 'space' as
      delimiter. However, in iCalendar, it uses 'comma' as delimiter.
   2) Use xs:dateTime replace RFC 2445 DATE-TIME
   3) Use xs:duration replace RFC 2445 DURATION
   4) The tzid and tzurl is still necessary though the xs:dateTime already
      contains time zone information. But the byhour attribute still
      need time zone information. Unless we use xs:time as the type for
      byhour. But xs:time also contains minute and second.
   5) Keep the others the same

   To provide service like

   "Call Mom at 9:00AM every Thanksgiving (4th Thursday of November)"

  CPL fragment is like:

  <time-switch>
    <time freq="yearly" bymonth="11" byday="+4TH" byhour="9" byminute="0">
      <location url="sip:[email-masked]">
        <call />
      </location>
    </time>
  </time-switch>

  In XML Schema, no pre-defined way to represent Thanksgiving.
  In CPL, it provides such way. However, it's not easy to represent the
  string like "+4TH" in XML schema, unless using string pattern. The
  string pattern looks awful. Several ways to define the string pattern,
  they are listed as below. Please comments.

** Long format, with the number as 0~366
	<xs:simpleType name="ExtendedDayType">
		<xs:restriction base="xs:string">
			<xs:pattern
value="([+|-]?([1-9]|[1-9][0-9]|[1-2][0-9][0-9]|[3][0-5][0-9]|[3][6][0-6]))?([M|m][O|o]|[T|t][U|u]|[W|w][E|e]|[T|t][H|h]|[F|f][R|r]|[S|s][A|a]|[S|s][U|u])"/>
		</xs:restriction>
	</xs:simpleType>

** Long format, simplified, with the number as 0~999
	<xs:simpleType name="ExtendedDayType">
		<xs:restriction base="xs:string">
			<xs:pattern
value="([+|-]?[0-9]{0,3}([M|m][O|o]|[T|t][U|u]|[W|w][E|e]|[T|t][H|h]|[F|f][R|r]|[S|s][A|a]|[S|s][U|u])"/>
		</xs:restriction>
	</xs:simpleType>

** Seems this one is easier to understand
	<xs:simpleType name="ExtendedDayType">
		<xs:restriction base="xs:string">
			<xs:pattern value="[+|-]?[0-9]{0,3}[M|m][O|o]"/>
			<xs:pattern value="[+|-]?[0-9]{0,3}[T|t][U|u]"/>
			<xs:pattern value="[+|-]?[0-9]{0,3}[W|w][E|e]"/>
			<xs:pattern value="[+|-]?[0-9]{0,3}[T|t][H|h]"/>
			<xs:pattern value="[+|-]?[0-9]{0,3}[F|f][R|r]"/>
			<xs:pattern value="[+|-]?[0-9]{0,3}[S|s][A|a]"/>
			<xs:pattern value="[+|-]?[0-9]{0,3}[S|s][U|u]"/>
		</xs:restriction>
	</xs:simpleType>

** More readable, but with annotation indicating this is case-insensitive
   (XML schema is case-sensitive, and no date type for weekday)
	<xs:simpleType name="ExtendedDayType">
		<xs:annotation>case-insensitive</xs:annotation>
		<xs:restriction base="xs:string">
			<xs:pattern value="[+|-]?[0-9]{0,3}MO"/>
			<xs:pattern value="[+|-]?[0-9]{0,3}TU"/>
			<xs:pattern value="[+|-]?[0-9]{0,3}WE"/>
			<xs:pattern value="[+|-]?[0-9]{0,3}TH"/>
			<xs:pattern value="[+|-]?[0-9]{0,3}FR"/>
			<xs:pattern value="[+|-]?[0-9]{0,3}SA"/>
			<xs:pattern value="[+|-]?[0-9]{0,3}SU"/>
		</xs:restriction>
	</xs:simpleType>

** More readable, no restriction on number, since for yearly, monthly
   weekly, the number range is different any way.
	<xs:simpleType name="ExtendedDayType">
		<xs:annotation>case-insensitive</xs:annotation>
		<xs:annotation>for yearly, number range from -365~365
                </xs:annotation>
		<xs:annotation>for monthly, number range from -30~30
                </xs:annotation>
		<xs:annotation>for weekly, number range from -6~6
                </xs:annotation>
		<xs:restriction base="xs:string">
			<xs:pattern value="[+|-]?[0-9]*MO"/>
			<xs:pattern value="[+|-]?[0-9]*TU"/>
			<xs:pattern value="[+|-]?[0-9]*WE"/>
			<xs:pattern value="[+|-]?[0-9]*TH"/>
			<xs:pattern value="[+|-]?[0-9]*FR"/>
			<xs:pattern value="[+|-]?[0-9]*SA"/>
			<xs:pattern value="[+|-]?[0-9]*SU"/>
		</xs:restriction>
	</xs:simpleType>

Thanks!

-Xiaotao

==========================================================
Name      : Xiaotao Wu
Email     : [email-masked], [email-masked]
Homepage  : http://www.cs.columbia.edu/~xiaotaow
Phone     : (212)939-7054,  Fax: (801)751-0217
Phone-PC  : (212)939-7133
SIP       : sip:[email-masked]
Office    : Room 506, Mudd building, West 120th
==========================================================

_______________________________________________
Iptel mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/iptel

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 19 Mar 2003 01:33:21 -0500

Well, before we get into details, I think we need to ask the question of 
whether folks are interested in developing a schema for CPL. Here are my 
thoughts on this.

I believe that any such schema would need to be compatible with the DTD. 
Specifically, any CPL which validates against the DTD must also be valid 
against the schema, and anything which is not valid against the DTD 
cannot be valid against the schema. Otherwise, we break 
interoperability, and I dont see the value in that. Breaking interop 
just to enable schema validation seems backwards.

So, although I like schemas, it is not clear to me that there is value 
in expending IETF resources to develop a schema. I could be convinced if 
there were a specific protocol problem that such a change was solving. 
But, defining a schema just to have a schema, doesnt seem that useful.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Xiaotao Wu <[email-masked]>
Date: Wed, 19 Mar 2003 14:27:08 -0500 (EST)

> in expending IETF resources to develop a schema. I could be convinced if

Here is what I thought why it is valuable to have a CPL schema.

There are many advantages of using schema, such as better type checking,
schema itself is in XML so no additional parser needed etc. These
advantages are not enough for spending time on creating the schema.

The most important advantage that causes me to spend time on a schema for
CPL is the extensibility of XML Schema.

CPL has many carefully designed switches and actions. And I think for
light-weight service applications, CPL is a very good language to use.
However, the CPL draft limits the functions to only network servers. There
should be CPL extensions so other entities, such as user agents, presence
agents can also use CPL scripts to perform services. Though in CPL draft,
such kind of extensions are allowed, based on my experience on writing CPL
extensions for presence information handling and XML schema for CPL, I
feel only schema can handle the extensibility nicely. DTD cannot do that.

Here is an example.

For CPL extensions for presence information, we need an event-switch to
perform different actions based on different events (online, offline).
So, we added an event-switch. However, we found that simply adding a
new element is not enough. This element should be able to be inside
the other switches, and the other switches can also be inside this
switch. Any actions should also be able to be in the new defined switch.
The only way to do this is to MODIFY the 'Switch' ENTITY defined in the
original CPL DTD.

In original CPL DTD

     <!ENTITY % Switch 'address-switch|string-switch|time-switch|
                         priority-switch' >

In new CPL DTD

     <!ENTITY % Switch 'address-switch|string-switch|time-switch|
                         priority-switch|event-switch' >
                                         ____________

So, everytime a new switch, or a new action, or a new top-level action is
added in, the DTD has to be modified. The extensions cannot be added in a
compositional way.

But with XML Schema, by using the substitutionGroup, and the abstract
type, the extensibility can be handled very nicely. New switches, actions
can be generated from base abstract type, just like generating sub-class
from parent class in C++.

We define an abstract switch, with abstract type 'Switchtype'

     <xs:complexType name="SwitchType" abstract="true"/>
     <xs:element name="switch" type="SwitchType"/>

Follow the CPL structure, Node is defined as below:

     <xs:group name="Node">
       <xs:choice>
         <xs:element ref="switch" minOccurs="0"/>
                         --------
         <xs:group ref="Location" minOccurs="0"/>
         <xs:group ref="Sub" minOccurs="0"/>
         <xs:element ref="action" minOccurs="0" maxOccurs="unbounded"/>
       </xs:choice>
     </xs:group>

We can then have any new defined switches as the substitutionGroup of the
abstract 'switch' element, with type extended from the abstract SwitchType
type.

<xs:element name="event-switch" type="EventSwitchType"
  substitutionGroup="CPL:switch"/>

<xs:complexType name="EventSwitchType">
  <xs:complexContent>
    <xs:extension base="CPL:SwitchType">
      <xs:sequence>
       .....
      </xs:sequence>
    </xs:extension>
  </xs:complexContent>
</xs:complexType>

In this way, the new defined switch can be in whatever place the other
switches can be in. With the very basic CPL schema defined, any new
extensions do not need to touch the basic CPL schema for new switches,
actions. New extensions can be added in a compositional way.

So, I think to extend the usage of CPL, the XML schema for CPL is
necessary.

Thanks!

-Xiaotao

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 20 Mar 2003 22:56:30 -0500

Well, the group is not currently chartered to do CPL extensions, or to 
develop a new schema for CPL. As with anything else, IETF working groups 
do work they are chartered to do, and items get added to the charter by 
AD request when their is interest from the group.

So, I ask the group - please speak up if you are interested in pursuing 
CPL extensions, and believe that defining a schema is something we 
should work on.

Thanks,
-Jonathan R.