Re: SET-PROPERTY ?

I agree with you with that.If we have got consensus on that,i think jamal 
could close the issue about that and add the consensus we got to the 
issue,thanks.
Yours,Fenggen
>From: "Joel M. Halpern" <[email protected]>
>Reply-To: "Joel M. Halpern" <[email protected]>
>To: [email protected]
>Subject: Re: SET-PROPERTY ?
>Date: Tue, 17 Oct 2006 11:14:48 -0400
>
>We could have used a flag to indicate that what was wanted was the 
>property information.
>After discussion, we concluded that using a distinct operation, and 
>a flag for the case where one needed to get only part of the 
>property information, seemed cleaner.
>Obviously, that is a subjective matter on which reasonable folks may 
>differ.
>
>However, I am reluctant to change the agreed approach without a 
>stronger reason.
>(Among other things, I am not sure I have remembered all the issues 
>that we went through the first time.)
>
>Yours,
>Joel M. Halpern
>
>At 10:49 AM 10/17/2006, Wang,Weiming wrote:
>>I agree the property is usually simple. There is almost no 
>>possibility to use an array in a property, but it is quite possible 
>>for desiners to tend to use two level property.
>>
>>To associate a SET/GET-Property with an in-property flag may be a 
>>solution. But in this case, to compare with, I think the scheme to 
>>use a <property> and a property flag in the path looks better - 
>>much more flexible and insistant to our path-data format.  With 
>>this scheme, we even could use one GET operation to get a data of 
>>an element and simultaneously get the property of the element, 
>>which are very useful use scenario for a property.
>>
>>I do hope you could think of this scheme.
>>
>>thanks,
>>weiming
>>----- Original Message -----
>>From: "Joel M. Halpern" <[email protected]>
>>
>>We actually discussed all of these cases, and I
>>expect that the text for the protocol will deal
>>with them.  There does need to be one flag used
>>in paths to indicate that the path refers to a
>>part of the property information itself, not the
>>information whose property is being sought.  (If
>>that is too complicated, properties are simple
>>enough and used rarely enough that we could
>>probably live with just always getting and setting a full property 
>>structure.)
>>
>>Your question 1 was what does it mean to say
>>GET-PROPERTY
>>      Path = P
>>          |- Path = 1
>>          |- Path = 2
>>
>>This will get the property structure for P.1 and
>>the property structure for P.2.
>>If we wanted the elements 1 and 2 of P's
>>properties, we would set the in-property flag for the inner paths:
>>GET-PROPERTY
>>      Path = P
>>        |- (in-property) Path = 1
>>        |- (in-property) Path = 2
>>
>>Because Properties are relatively simple
>>structures, we do not ever need to nest
>>in-property paths.  For clarity, and to ensure
>>that all cases are fully defined any path within
>>the in-property flag is in-property.  You never
>>need to bounce out.  And elements of properties
>>do not themselves have properties (that would be
>>an infinite regress.)  That restriction also is
>>sensible only because properties are simple
>>information.  If we had arrays inside properties,
>>we would have a complete mess. (And it would be a
>>mess with any approach we used.)
>>
>>I believe this also disambiguates your question
>>2, which is about property 1 of P and property 1 of P.1.
>>
>>Yours,
>>Joel M. Halpern
>>
>>At 08:33 AM 10/17/2006, Wang,Weiming wrote:
>> >Two possible ambiguities:
>> >1. with nested Path-data
>> >Say P is the path referenced to an element which
>> >has elements 1 and 2,  all with individual
>> >properties.  P element also has its own
>> >property, and the property has property of elements 1 and 2.
>> >Now we want to get properties of P's elements 1
>> >and 2 with GET-Property operation, we use a
>> >nested path-data format for it. The nested path-data can be 
>>expressed as
>> >
>> >GET-PROPERTY
>> >     Path-data  - Path=P
>> >               |-----Path-data  Path=1
>> >               |-----Path-data  Path=2
>> >
>> >But, but the problem is , above format can also
>> >be understood as: "to get property of P's
>> >property's element 1 and 2" rather than "to get
>> >property of P's elements 1 and 2's property". Obviously, they are 
>>different.
>> >
>> >2. with possible more than one level of property element 
>>operation
>> >Say P is the path refered to an element which
>> >has an element 1, the element has property
>> >element 1. P element also has its own property
>> >with element 1, and the element has second level element 1.
>> >Now we want to get P's element 1's element 1's
>> >property , we may use a path as P.1.1, but at
>> >the same time, this can also be understood
>> >as  to get P's property's element 1's element 1. That's also 
>>different.
>> >
>> >Of couse, we may put more text on above
>> >GET-property operations to try to remove the
>> >ambiguity, such as to limit GET-Property
>> >operation not for nested operation or there
>> >should be only one level of property element.
>> >but, if we have to do like this, it may be
>> >proven that the operation definition is with a bad grace.
>> >
>> >I'm not sure if above case has ever been considered.
>> >
>> >thanks,
>> >weiming
>> >
>> >----- Original Message -----
>> >From: "Joel M. Halpern" <[email protected]>
>> >
>> >I do not see the parallel with the "key" element.
>> >As for ambiguity, that depends upon the actual text.
>> >When the protocol team authors finish the text,
>> >if there is ambiguity we will fix it.  If it
>> >proves difficult to write clear text, then we will look at 
>>alternatives.
>> >
>> >Yours,
>> >Joel
>> >
>> >At 01:42 AM 10/17/2006, Wang,Weiming wrote:
>> > >There are also ambiguities with SET-PROPERTY
>> > >approach, e.g., when we use nested PATH-DATAs,
>> > >and when we later have to define properties with
>> > >more than one level of elements (thought
>> > >currently I found they are all only one level).
>> > >
>> > >When I checked the property issue again, I just
>> > >think that it is an element more like the key
>> > >element in terms of its apperance and operation way.
>> > >
>> > >If changing the protocol is inevitable, I
>> > >propose to use quite the same way as the
>> > >approach to key element, to totally avoid
>> > >ambituity and make enough flexibility. We may
>> > >have to adopt two bodies, one is the <property>
>> > >element, another is to associate a flag in the
>> > path to indicate the property.
>> > >
>> > >I suppose we may decide it very soon.
>> > >
>> > >thanks,
>> > >Weiming
>> > >
>> > >----- Original Message -----
>> > >From: "Joel M. Halpern" <[email protected]>
>> > >
>> > >We looked at the option of just assigning an ID
>> > >9either fixed or declared per element) for the property 
>>information.
>> > >
>> > >There were multiple issues, some minor.  The most
>> > >obvious major issue is the handling of arrays
>> > >(and events on array elements).  An array with
>> > >path P, has its elements referenced by the paths
>> > >P.0, P.1, ...  Hence, we can not also use P.1 to
>> > >refer to the array properties.  And arrays are
>> > >one of the things which really need properties.
>> > >
>> > >Yours,
>> > >Joel M. Halpern
>> > >
>> > >PS: Your examples seem to focus on the
>> > >events.  The event use of properties was driven
>> > >by the need to introduce the properties.  If
>> > >properties were not there, I would be happy to
>> > >handle the event information in other ways.
>> > >
>> > >At 01:41 AM 10/16/2006, Weiming Wang wrote:
>> > > >I seems more flexible to set an element called
>> > > ><property> to deal with the requierment. A
>> > > >property element is just to assign an element id
>> > > >and the property datatype. In this way,
>> > > >everything is united under one uniform Path-Data
>> > > >format and it also makes LFB definition document
>> > > >more readable. Taking an examle as below:
>> > > >  <attribute elementID="1">
>> > > >     <name>foo1</name>
>> > > >     <property elementID="1">baseElementProperty</property>
>> > > >...
>> > > ></attribute>
>> > > ><event eventID="1">
>> > > >     <name>foo2</name>
>> > > >     <property id="1">eventProperty</property>
>> > > >...
>> > > ></event>
>> > > >
>> > > >This also makes possible more than one kind of
>> > > >property type defined for the same element. I
>> > > >just noticed that to mandate every element with
>> > > >one mandatory property just wastes lots of
>> > > >resources. For e.g., for an event, in most
>> > > >cases, it is not necessary for event having
>> > > >properties like threshold,
>> > > >eventHysteresis,eventHysteresis(I suppose a typo
>> > > >here), eventCount as defined in mode draft p.68.
>> > > >
>> > > >thanks,
>> > > >Weiming
>> > > >
>> > > >----- Original Message -----
>> > > >From: "Joel M. Halpern" <[email protected]>
>> > > >
>> > > >This was discussed extensively on the list.
>> > > >The SET-PROPERTY / GET-PROEPRTY mechanism was
>> > > >actually introduced to get around a completely
>> > > >different set of problems.  After examining it,
>> > > >we realized that it was a good way to solve
>> > > >sseveral problems, including alias targeting and event 
>>subscription.
>> > > >
>> > > >The alternative for trying to create identifiers
>> > > >for all of these things in the regular SET / GET
>> > > >space was a real pain.  And the semantics were quite 
>>misleading.
>> > > >
>> > > >Yours,
>> > > >Joel M. Halpern
>> > > >
>> > > >At 09:50 AM 10/14/2006, Wang,Weiming wrote:
>> > > > >I havn't noticed this arguement till recent days
>> > > > >when I'm trying to write some events xml for FE
>> > > > >Object. I think Fenggen has raised a very important 
>>question.
>> > > > >
>> > > > >I'd like to make a brief recall to the history
>> > > > >related to this event subscription issue in the
>> > > > >protocol team work in recent years.
>> > > > >At the very begining, there were two thoughts
>> > > > >regarding how to subscribe an event, one was to
>> > > > >take a specific message or operation type called
>> > > > >subcribe/unsubscribe for the purpose, the other
>> > > > >was to ask event definitions to take a flag as a
>> > > > >subscription/unsubscription flag, then to
>> > > > >configure the flag to sub/unsub the events.
>> > > > >After a long discussion, it has reached a
>> > > > >consensus that a subcription flag will be more
>> > > > >efficient and be the prefered one. Hence, the
>> > > > >protocol has always followed the consensus till now.
>> > > > >
>> > > > >The SET-PROPERTY actually takes the same scheme
>> > > > >as to define an operation type specifically for
>> > > > >subscribe/unsubscribe. I'm not sure why it comes
>> > > > >this idea again. The protocol document might be
>> > > > >a little embarassed if it should be  repaired in this way 
>>right now.
>> > > > >
>> > > > >Thanks,
>> > > > >Weiming
>> > > > >
>> > > > >----- Original Message -----
>> > > > >From: "Joel M. Halpern" <[email protected]>
>> > > > >
>> > > > >You are right about SET-PROPERTY and
>> > > > >GET-PROPERTY!  Protocol Team, is that being added
>> > > > >to the protocol document.  (This is not a recent change.)
>> > > > >
>> > > > >I am not sure I understand the other question.
>> > > > >A given event definition can have only one event target.
>> > > > >An event definition is the event name, the event
>> > > > >target, the event Condition (which describes the
>> > > > >specific condition under which the event is
>> > > > >triggered) and the event Report (which indicates what is 
>>reported.
>> > > > >A given definition has a single target, a single
>> > > > >condition, and a single reports (which has a list of fields 
>>to report.
>> > > > >We do not need "eventTargets" or
>> > > > >"eventConditions", because each event has one target and 
>>one conidition.
>> > > > >
>> > > > >If we had allowed multiple conditions in an event
>> > > > >definition, then the occurrence of the event
>> > > > >would have to have some way of indicating which
>> > > > >condition had occurred.  Similarly, if there
>> > > > >could be multiple targets we would need to
>> > > > >indicate which target had detected the
>> > > > >problem.  Withthe current structure, that problem does not 
>>arise.
>> > > > >
>> > > > >
>> > > > >At 01:40 AM 9/29/2006, Jia Fenggen wrote:
>> > > > > >I notified in model draft when one wants to
>> > > > > >subcribe to an event,he uses SET-PROPERTY
>> > > > > >operation and use the path composed of event
>> > > > > >base id plus event id,here is a problem because
>> > > > > >we haven't defined operation SET-PROPERTY in
>> > > > > >protocol draft,and even a broader question,how
>> > > > > >should we do to get and set LFB element
>> > > > > >properities,how should the path be used,if I
>> > > > > >misunderstand something here,I am sorry.
>> > > > > >And another question,because i am not an xml
>> > > > > >expert,i don't know why we not define
>> > <eventTarget> element as follows:
>> > > > > ><eventTargets>
>> > > > > >   <eventTarget>
>> > > > > >      <eventField>..</eventField>
>> > > > > >      <eventSubscript>..</eventSubcript>
>> > > > > >   </eventTarget>
>> > > > > >   <eventTarget>
>> > > > > >      <eventField>..</eventField>
>> > > > > >      <eventSubscript>..</eventSubcript>
>> > > > > >   </eventTarget>
>> > > > > >    ...
>> > > > > ></eventTarget>
>> > > > > >and the same question to <events> Element Conditions 
>>declaration.
>> > > > > >Yours,Fenggen
>> > > > > >
>> > > > > 
>> >_________________________________________________________________
>> > > > > >浜ㄤ涓澶х靛欢绯荤 MSN Hotmail  
>>http://www.hotmail.com

_________________________________________________________________
璐逛杞 MSN Explorer:   http://explorer.msn.com/lccn/