Re: SET-PROPERTY ?

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