Subject: RE: Yet more issues to resolve - <persistDuration>
William Your idea of using xsd:timeDuration makes complete sense. In fact my view is that we should use XML Schema types whenever possible. I've just not had the time to really learn the ins and outs of XML Schema ... I wonder why that is. On TimeToLive, this is in version 0.91 defined as a timeInstant is this OK? David -----Original Message----- From: William J. Kammerer [mailto:email@example.com] Sent: Thursday, January 04, 2001 12:34 PM To: firstname.lastname@example.org; email@example.com Subject: RE: Yet more issues to resolve - <persistDuration> Prasad Yendluri asked why PersistDuration (in the CPA/CPP) is limited to "days"? David Burdett replied that: ...if the message is being placed in some type of persistent storage such as a disk, then you probably would not want to clear it out too often. So setting it to whole days makes it a simpler value than the years, months, weeks, days, hours, minutes, millisecs?? that you might otherwise need. Another approach is to specify a single integer and then put the units in separately such as <persistDuration units="seconds">20</persistDuration> in the CPA. Would that work better? Maybe everything that smells like a "duration" should really be one (i.e., a Schema "xsd:timeDuration" type), as noted for <TimeToLive> in my comments on Spec Version 0.9a at http://lists.ebxml.org/archives/ebxml-transport/200012/msg00253.html. Then we would have complete freedom to specify days, hours, minutes, or any combination thereof. Using the ISO 8601 Duration, e.g., PT10H20M for 10 hours - 20 minutes, would be instantly recognizable the world over with no mess, no fuss and no ambiguity. (Hee, hee - just kidding - but it IS a standard!). Then David can persist for seconds or days, depending on his whim, without burdening the CPA with decisions about what is reasonable, or having to invent new time unit parameters. See the submission by Martin Bryan, "Datatyping for Electronic Data interchange - Draft CEN/ISSS Workshop Agreement," at http://www.cenorm.be/isss/Workshop/ec/Datatyping/data99_000.htm, for a description of schema timeDuration types. William J. Kammerer FORESIGHT Corp. 4950 Blazer Memorial Pkwy. Dublin, OH USA 43017-3305 +1 614 791-1600 Visit FORESIGHT Corp. at http://www.foresightcorp.com/ "Commerce for a New World"
eList eXpress LLC