|
Ref. 2.1.1, 4th paragraph:
The operation attribute describes the actual operation request as one of the following operations: get, create, modify, or delete. The further description of each operation is depended on the data model. Recommendation is that one attribute named "action" in the targeted element should specify the finer-grain action (attribute-as-action).
And 2.1.1, 8th paragraph:
The attribute "action" is closely associated with targeted element and specified by data model instead of operation model, which makes interface flexible and extensible.
Why is the conceptual space of “operations” (a.k.a. “actions”) split across both the operation model and the data model? This doesn’t seem right to me. IMO, the correct OOP decomposition of “finer-grain actions” would be to sub-class a base operations object, not inject “verb/adverb” constructs (operations & operation modifiers) into the “noun” space (data).
Morphing the example at the bottom of p. 5 a bit, consider the following:
<perform-request messageId="1234" operation="get" transaction="continue-on-error" xmlns="http://www.ietf.org/mops" xmlns:example="http://example.com/schema"> <example:running-config name="active"> <example:ospf name="process 1"> <example:area action = "">get-next"> <example:interface action="">get-first"> <address/> <adminStatus>"up"</adminStaus> </example:interface> </example:area> </example:ospf> <example:ospf name="process 45"> <example:area action = "">get-first"> <example:interface action="">get-next"> <address/> <adminStatus>"up"</adminStaus> </example:interface> </example:area> </example:ospf> </example:running-config> </perform-request>
The outer most action looks to be a simple “get”, but the two contained “<example:ospf…>” (data-space!) fragments modify that, and do so in different ways. One could argue that the meaning here can be well-defined (we’d have to decide what a “get-next” inside a “get-first” should do), but it is still confusing to me on first read (late at night, it could be confusing on the 8th read…).
“Attribute-as-operation”, where the attribute is formally part of a data schema but is nothing but a modifier of the semantics of an outer operation element from another schema, might turn out to be a can of worms…
-k
-----Original Message-----
Forwarding the following announcement from IETF announcement list.
A New Internet-Draft is available from the on-line Internet-Drafts directories.
Title : XML Network Management Interface Author(s) : W. Chen, K. Allen Filename : draft-weijing-netconf-interface-00.txt Pages : 23 Date : 2003-6-26
This document describes XML network management interface between network managed system and network managing system. The XML network management interface is intended for use in diverse network environment where transport and data model requirements vary greatly. It is unlikely that a single transport and data model specification will meet the needs of all anticipated service operators. Therefore, the XML network management interface is partitioned into the layered components.
A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-weijing-netconf-interface-00.txt
To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message.
Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-weijing-netconf-interface-00.txt".
A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
-- Weijing Chen
|