Re: SET-PROPERTY ?

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