ws-calendar — archive

Oh-Oh....

From: Michael Douglass <[email protected]>
To: [email protected]
Date: Mon, 13 Jun 2011 20:31:00 -0000

The way the schema is defined it's easy. In the ws-calendar extension we need to change  <xs:element name= gap type= xcal:DurationParameterType substitutionGroup= xcal:baseParameter /> (for context) to  <xs:element name= gap type= xcal:DurationParameterType substitutionGroup= xcal:baseParameter />  <xs:element name= granularity type= xcal:DurationPropType substitutionGroup= xcal:baseProperty /> and further down we have <xs:element name= granularity type= xcal:DurationValueType minOccurs= 0 maxOccurs= 1 /> which we change to <xs:element name= precision type= xcal:DurationValueType minOccurs= 0 maxOccurs= 1 /> We still need to change what is going to end up in the vavailability RFC but that's a whole other discussion - mostly for calconnect tc-xml On 06/13/2011 04:19 PM, Toby Considine wrote: [email protected] type= cite > I thought we were using Parameter so we would not have to change the underlying vavailability spec. I would be happy to be wrong, especially as Granularity is useful for general use of vavailability. So, are you saying lose the granularity, and add a property in iCalendar-availability-extension.xsd? tc He who fights with monsters should look to it that he himself does not become a monster, and if you stare long into an abyss, the abyss also stares into you. - Fredrich Nietzche Toby Considine TC9, Inc TC Chair: oBIX & WS-Calendar TC Editor: EMIX, EnergyInterop U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee Email: [email protected] Phone: (919)619-2104 http://www.tcnine.com/ blog: www.NewDaedalus.com From: Mike Douglass [ mailto:[email protected] ] Sent: Monday, June 13, 2011 4:09 PM To: [email protected] ; [email protected] Subject: Re: [ws-calendar] Oh-Oh.... I missed this message: - been fixing up some crises of my own here Where is it used as a parameter? I've searched the spec and the only place granularity turns up is as an element of the tolerance property. We did discuss adding it as a PROPERTY. The word parameter turns up at line 1053 - it should be property Also the work component is used incorrectly Replace WS-Calendar adds a single optional parameter to the [Vavailability] component. When a Granularity component is applied, it further defines the acceptable service invocation. WS-Calendar adds a single optional property to the [Vavailability] component. When a Granularity proeprty is applied, it further defines the acceptable service invocation. Section 3.3.1.3 is fine if we respecify the granularity as a property. Also at line 1409 it's mentioned again but isn't in the example following. As I recollect the discussion around this we had on Friday resulted in the following: 1. The Tolerance property has a granularity value element. This should be renamed to precision as that is what it's trying to express and it removes confusion with the following: 2. We add a granularity PROPERTY which can be applied to vavailability or availability to define the size of the 'chunks' of time The tolerance property can be applied to the calendar component to act as a default for the entire set of components or added as a property to a single component to override any default. I think the only change to the examples would be line 1100 and to add a granularity property somewhere around 1416-1463 I can send an updated schema with the changes On 06/11/2011 05:40 PM, Toby Considine wrote: In the schemas for ws-calendar, the granularity parameter was lost during some final edits. < xs:element name = granularity type = xcal:DurationParameterType substitutionGroup = xcal:baseParameter /> This should have appeared after line 21 of the schema file iCalendar-wscal-extensions.xsd The parameter appears in the Specification, and is used for several documented purposes. It is also critical to several parts of EMIX and Energy Interoperation. Its absence is due to an error in my quality checking of same late-arriving changes that modified the declarative patterns in some other schema types. It was discussed in Friday’s meeting, with the acknowledgement that this would drive the production of a PR04, with associated delays of other standards. No one in the quorate call was vwn aware that it Had dropped out until I brought it up. This is clearly a procedural violation, but if it can be fixed before the schemas go out, it would enable to the samples, specifications, and schemas to match. CC’ing the TC in the interests of transparency and to allow any of them to protest, if anything path is suggested to fixing this prior to publication. tc “The single biggest problem in communication is the illusion that it has taken place.” – George Bernard Shaw. Toby Considine TC9, Inc TC Chair: oBIX & WS-Calendar TC Editor: EMIX, EnergyInterop U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee Email: [email protected] Phone: (919)619-2104 http://www.tcnine.com/ blog: www.NewDaedalus.com Spam Not spam Forget previous vote -- Mike Douglass [email protected] Senior Systems Programmer Communication & Collaboration Technologies 518 276 6780(voice) 2809 (fax) Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180 -- Mike Douglass [email protected] Senior Systems Programmer Communication & Collaboration Technologies 518 276 6780(voice) 2809 (fax) Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180