Re: Deja vu Again

[Randy Presuhn <rpresuhn@dorothy.bmc.com>]

Hi -

> Message-Id: <5.1.0.14.2.20020627142559.02640828@fedex.cisco.com>
> Date: Thu, 27 Jun 2002 14:54:20 -0700
> To: Randy Presuhn <rpresuhn@dorothy.bmc.com>
> From: Andy Bierman <abierman@cisco.com>
> Subject: Re: Deja vu Again
> Cc: xmlconf@ops.ietf.org
...
> >There are at least three different DTDs/Schemas that we could
> >be talking about in xmlconf, and we need to decide which ones
> >we're going to do:
> >    - schema for the basic protocol operations
> >    - payload metaschema
> >    - schemas for managing particular gizmos
> >
> >I hope we're agreeing that it's the first two and not the
> >third that we're talking about.
> 
> I'm not sure what a metaschema is.
> If it means the payload will contain an opaque element like 
>   <command>bunch of proprietary text</command> 
> then I don't think we agree.  I would rather see something like:
> 
>   <command xmlns="http://www.acme.com/commands";>
>      <acme-top-level-element>
>          <acme-nested-element>
>             bunch of proprietary text or maybe
>             some more nested elements (parameters)
>          </acme-nested-element>
>      </acme-top-level-element>
>   </command>
...

This is something I think we may need to permit, but
should strongly discourage.

If we say anything at all about the payload part,
I'd rather see something roughly like
   ...
   <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.)

 ------------------------------------------------------
 Randy Presuhn          BMC Software, Inc.  1-3141
 randy_presuhn@bmc.com  2141 North First Street
 Tel: +1 408 546-1006   San José, California 95131  USA
 ------------------------------------------------------
 My opinions and BMC's are independent variables.
 ------------------------------------------------------

--
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/>