Re: Deja vu Again

["David T. Perkins" <dperkins@dsperkins.com>]

HI,

There is a trade-off with the approach that you have taken. And
that is to have all "values" as strings, and not have a type
associated with the "typ". This is deferred for the "next round"
of checking (and interpreting). 

By the way, the below is getting to look a lot like CMIP....
If we go that way, then there could be several ways to identify
an instance. Which will make app writers happy, but maybe
"agent" writers grumble about the additional support for
each indexing (identification) scheme.

Randy - how would you do "embedded" object classes?


>   <instance-data>
>      <object-class typ="usmUserEntry" href="http://www.ietf.org/whatever";>
>      <instance-name>
>          <index typ=usmUserEngineID value="0x00000">
>          <index typ=usmUserName value="Andy">
>      </instance-name>
>      <attribute-list>
>          <attribute typ=usmUserSecurityName value="Bierman">
>          <attribute typ=usmUserPrivProtocol value="usmNoAuthProtocol">
>          ...
>      </attribute-list>
>   </instance-data>
>
>where all the "typ" semantics can be resolved by looking in
>http://www.acme.com/classes (though, just as with WSDL
>and friends one would not normally do this at runtime!)
>
>I think each of these levels of encapsulation, especially
>the higher-level protocol stuff, should really probably
>be kept in line with the encapsulation notions in
>http://www.w3.org/TR/2002/WD-xmlp-reqs-20020626#N774 (Note
>that this document also raises the possibility of providing
>transaction support.)

Regards,
/david t. perkins


--
to unsubscribe send a message to xmlconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/xmlconf/>