Re: [Forces-protocol] Re: querry message (path vs attribute)

[Jamal Hadi Salim <[e-mail]>]

On Sun, 2004-10-24 at 23:41, Wang,Weiming wrote:
> Jamal,
> 
> Hormuzd, pls also give some feadback. I also add Joel to the list again for the
> discussion.
> 
> Regards,
> Weiming
> ----- Original Message -----
> From: "Jamal Hadi Salim" <[e-mail]>
> Subject: Re: [Forces-protocol] Re: querry message (path vs attribute)
> 
> 
> > Weiming,
> >
> > On Sun, 2004-10-24 at 07:40, Wang,Weiming wrote:
> > > Jamal,
> > >
> > > Firstly, I think it may be unwise to remove some editorial note when the
> isuuse
> > > is still under discussion. I can clearly see many different opinions
> regarding
> > > the issue. Then, some of my thougt on adding such an editorial note as
> below.
> > >
> >
> > Is the concept of path still under discussion Weiming? Thats not my
> > impression. And if not, why does it matter if the path is constructed
> > from a single attribute or via table of table7 index 3 which is table8 ?
> [Weiming]Jamal, it's really a under discussion topic. I can see different view
> other than from me, you may miss me one person :), but it's true we have more. I
> stopped the discussion for I paid more attention to draft rewriting. At least I
> think Hormuzd also has some different views.
> >
> > > Regards,
> > > Weiming
> > > ----- Original Message -----
> > > From: "Jamal Hadi Salim" <[e-mail]>
> > >
> > > >
> > > > I think we need to add a definition for attribute.
> > > > As far as iam concerned there is no such thing as a "attribute ID".
> > > [Weiming] Then, I just can not see how we can recognize different attributes
> in
> > > a LFB. Note that a 'Path' is a ID that is used and defined by USERS rather
> than
> > > standadized by IETF, therefore it's impossible to recoganize different
> > > attributes by 'path', and more, if the attribute ID is defined by USERS,
> there
> > > will be no interoperability. What I see the 'Attribute ID' is a standardized
> by
> > > IANA Identifier that is assigned to different attributes in all LFBs.
> >
> > The attribute IDs are defined by the person(s) who create the XML.
> > The document/ClassID - that i can see as being owned by IANA.
> 
> [Weiming] Even if the attribute(type) ID will only be defined by XML which
> define LFBs (I still see the necessity for IANA to standardize the ID), it has
> already meant the ID will not be assigned by USERS.

Not defined by users, rather static - defined at LFB XML template
creation time. OTOH, there are some more dynamic IDs that are usable
such as a table index.

>  Then, if you want to have
> 'path' include the ID, I suppose we should leave a specific section for the ID,
> and the use of the section will be limited only for attribute type ID. To do
> like this, I more prefer to have it as a separate spicific field. Note that I'm
> not saying in any case, the 'path' is useless, I just suppose it can be put in
> Data field. Actually hat I think the more reasonable addressing map for LFB
> should be as follows:
> 
>                                 LFB class
>                                /      \
>                         LFB Instance  ...
>                         /    \
>              Attribue Type   ...
>                 /         \
>     Path to entries inside  ...
> 
> Rather than:
>                                         LFB class
>                                        /      \
>                                 LFB Instance  ...
>                                 /        \
>                Path to  entries   ...
>                 /         \
>         Attribute Type    ...
> 

Why do you have the attribute type? To get to the attribute i.e to know
its path, you dont need to know its type.

> The path can really be defined in Data as:
> 
> Data : = Path <Entry>
> 
> Can you tell me what's the harm if we just define the 'path' one step down to
> the Data field. I just see it more flexible.
> 

Above is what we have been refering to as path-data. Entry is the data.


> 
> >
> > > > What you specify is a path similar to an OID. Whether that path
> > > > happens to be on an attribute, a table, an entry is not important
> > > I see it may be important, the reason is as above.
> > > > because that wuill be the lement you are pointing to.
> > > > so lets remove this from the query section
> > > [Weiming]I'v already put the 'path' as main select and the 'attribute
> ID/table
> > > ID' as a select for discussion. I don't have any intention to deny the
> 'path'.
> > > Therefore, I don't think it's reasonable currently to remove the note.
> > >
> >
> > I think we need to define how a path is selected once; then use the word
> > path everywhere.
> [Weiming]So can you give more definition for the 'Path' then? Does it include
> 'AttributeTypeID'?
> 

'AttributeTypeID' is not needed to get to the element. But the ID is
needed. I have attached the noop LFB we looked at a while back, it may
help reminding you a little ;->

cheers,
jamal

_______________________________________________
Forces-protocol mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/forces-protocol