Re: SET-PROPERTY ?

First off, you are mixing two different questions 
that are really quite separate.

Whether we use a SET-PROPERTY operation (with a 
flag if one needs to get/set information within 
the property) vs using a flag to indicate that 
one wants the property information for a given 
path is one issue.  I find the current approach 
conceptually cleaner.  Yes, your approach allows 
one to combine property manipulation with element 
manipulation in the same SET/GET.
a) I consider that pretty unlikely.
b) they can be in the same message, with the 
minor overhead of an additional operation header.

The other issue is whether we use a freestanding 
property definition, or require a property 
declaration for each element.  Requiring the 
property declaration for each element introduces 
significant human complexity.  It means that we 
have to include essentially the same information 
for each and every element we declare.  This is 
simply redundant.  It is much more effective to 
define what the property information is for each type of information.
In particular, there is no intention of having 
the LFB definer define the "properties" for the LFB elements.

Yours,
Joel M. Halpern

At 09:55 AM 10/20/2006, Wang,Weiming wrote:
>We never had the SET-PROPERTY issue set in the 
>issue tracker for the protocol, that might be 
>the reason why it was not so widely notified 
>that time and even was removed after had been 
>added. To my knowledge, it was not a general consensus. not sure others memery?
>
>Still, I want to make some comparison with the two schemes:
>1. Scheme1: to use a special operation 
>SET/GET-PROPERTY with 'property' flag in the 
>path to further indicate it, while keeping 
>property as an implicit element in XML definitions.
>2. Scheme2: not use any special operation, 
>instead, to use a special <property> element to 
>explicitly express property, and with a 
>'property' flag in the path to further indicate it.
>
>I just want to agree that, compared with scheme1, scheme2 is:
>1. more formal for xml definitions, because 
>scheme1 uses an implicit and default element 
>called <property>, which are different from 
>types of elements. I'm also not very sure if 
>such use of implicit and default element is 
>allowed, or against XML specifications or not? 
>While when we use an explicit <property> we will 
>get a complete and clear xml definition for an 
>LFB without any implicit element.
>
>2. Scheme2 makes it possible for one SET/GET 
>operation to set or get general data and 
>property data of an element concurrently. For 
>Scheme1, it has to use two operations: SET/GET, 
>and SET/GET-PROPERTY to do this.  Note that, it 
>may be useful to concurrently  SET/GET general 
>data and property data of an element.
>
>thanks,
>Weiming
>
>----- Original Message -----
>From: "Joel M. Halpern" <[email protected]>
>Subject: 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