[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
SV: IPTEL spec and iCalendar
I can relate to this from a SkiCal angle. Though SkiCal is an extension
of iCal and CPL a “call processing language” using XML syntax, two quite
divergent efforts, the authors of both drafts have tried to reuse previous
work and not reinvent when possible.
CPL uses XML syntax. ( Though I wonder if they took a good look at RDF,
which might have suited their purposes even better.)
In §2.4 XML Structure they equate “nodes” and “outputs” with “XML tags”
(I believe they should have used the term “Elements”) and “parameters” with
“XML tag Attributes”. (again – skip the tag!) so I believe the map is…
(CPL Nodes & Outputs) eqv. (Mime-directory Component Properties) eqv. (XML
(CPL Parameters) eqv. (Mime-directory Property Properties) eqv. (XML
I am not sure where this puts Calendar Components – but they are not part of
the deal here so that is irrelevant. For reference here is the Map that
Frank Dawson did in his iCal DTD from 19990220
(Mime Directory Calendar Components) eqv. (XML Elements)
(Mime Directory Calendar Properties) eqv. (XML Attributes)
(Mime Directory Component Properties) eqv. (XML Elements)
(Mime Directory Property Parameters) eqv. (XML Attributes)
(Mime Directory Value Types) eqv. (XML Value Types)
In § 5.3 Time switches, the CPL authors reference first tzid and tzurl, and
then dtstart, dtend/duration using the term “parameters”. Actually in 2445
TZID and TZURL are Properties but tzid is also confusingly a general
Other names referred to as parameters are:
all of which are Component Properties in 2445
which are value type components of the Recurrence Rules value type: RECUR
in 2445 and processed first and independently from…
which are also value type components of the Recurrence Rules and not
properties and not parameters either..
In other words there is a bit of a term muddle here which should be worked
out. If Properties, property parameters and property values are all going
to turn into parameters - be careful about it. At least be careful if some
sort of interoperability with iCal applications is intended.
I also would caution against using attributes to qualify their sibling
attributes rather than their parent element as the authors have done.
This is not good ER. One solution would be to nest;
Of course the “real” iCal solution would be to continue with the entire time
recurrence declared as RECUR property values just as they are in 2445;
In other words sticking to the value method used by iCal.
I have been planning to do a map between the date-time value types of 2445
and those of XML-schemas (also a ISO8601 derivative, but that is WIP. If
any one else has done that it would be nice to see it on the list –
otherwise I will proceed.