The Less Restricted Syntax Rusty Lusk, Narayan Desai, Rick Bradshaw

1
The Less Restricted Syntax Rusty Lusk,
Narayan Desai, Rick Bradshaw
2
Outline

• The syntax style issue
• Review of last meeting
• Syntax discussion of two syntax families
  restriction syntax and SSSRMAP syntax
• best of both worlds suggestion
• Desirable features of XML syntax style
• Presentation of Less Restricted syntax
• BNF
• Examples

3
The Syntax Style Issue

• Initially, we agreed on XML (because of multiple
  3rd-party parsers and the usefulness of schemas
  for specification and for validation) and sockets
  (because of universality) as the basis of a
  common communication mechanism.
• Did not standardize on wire protocol instead
  allowed multiple ones, plus a service directory
  to keep track of which component used which. The
  communication library hides the existence of
  multiple protocols from component code.

4
The Syntax Style Issue (cont.)

• Did not standardize on XML style, so multiple
  components were developed using quite different
  styles
• At the last meeting we discussed two families (RS
  and SSSRMAP)
• Both have substantial investment in components
  that use them
• Both can co-exist, and do so in current
  distribution
• Last meetings discussion improved understanding
  of both
• Suggestions for improvement were suggested at the
  last meeting and dubbed the less restricted
  syntax.

5
Areas of Agreement

• Common goal command language in XML
• Object-orientation a plus
• At abstract level, needs to apply a function to a
  collection of objects
• Individual components will deal with different
  objects and different functions
• Steps
• Identification of sets of objects
• Or construction
• Specification of function (with arguments)
• Construction of response message
• There are different ways of doing this
• RS, SSSRMAP, others

6
Desirable Features of an XML Style

• Completeness
• If you can think it, you can write it
• High value of validation
• Function signature type checking
• Protection of components from poorly formed
  messages
• Simplified component code
• Extent to which documentation is expressed in
  schema
• Readability
• Can a human understand the XML text?
• Conciseness
• Desirable, but might conflict with readability
• Scalability
• Atomicity
• Can race conditions be avoided?

7
Things to Look for in Any Syntax

• A command message does three things
• Matching a set of objects in components data
  store
• Either constructs them or identifies them
• Can use similar syntax
• Applies a function with arguments to that set of
  objects
• Constructs return message
• May be complex, containing partial information
  about objects identified

8
The Best of Both Worlds(Eliminating the worst of
both worlds)

• Keep high-level specification of commands as in
  RS, to raise value of validation
• Move attributes in RS to subobjects as in SSSRMAP
• Provides more room (in attribute space) for
  specifying matching details
• Explicitly specify fields to return as in
  SSSRMAP, but using attribute space for
  conciseness
• Make it simple to simple things, and possible to
  do complicated things.

9
Differences Between RS and LRS

• ltget-node-stategt
• ltnode-state nodeccn22 adminstate state
  /gt
• lt/get-node-stategt
• Becomes
• ltGetNodeStategt
• ltNodeStategt
• ltNodegtccn22lt/Nodegt
• ltAdminState matchfalse /gt
• ltState matchfalse /gt
• lt/NodeStategt
• lt/GetNodeStategt

10
LRS BNF

• InMsg ltCommand Argumentsgt
• Specification
• lt/Commandgt
• Command identifier
• Arguments Argument Argument
  Arguments
• Argument identifieridentifier
• identifier letter letter identifier
• OutMsg ltContainerNamegt
• Objects
• lt/ContainerNamegt
• Objects Object Object
  Objects

11
Specifications

• Specification ObjectDescription
• ObjectDescription
  Specification (must match one or more)
• ObjectDescription ltObjectNamegt
• 
  ObjectDetails
• 
  lt/ObjectName
• ObjectName identifier
• ObjectDetails Field Field
  ObjectDetails
•                     MultiField
  MultiField ObjectDetails
• Field ltFieldNamegt FieldValue
  lt/FieldNamegt
•                 ltFieldName Qualifiersgt
  FieldValue lt/FieldNamegt
• MultiField ltContainergtMFieldslt/Container
  gt
• MFields MFieldMFieldMFields
• MField Field

12
Qualifiers

• FieldName identifier
• Qualifiers Qualifier Qualifiers
• Qualifier BooleanKeyBooleanValue
• StringKeyStringValue
• BooleanKey 'negate''match''return'
• BooleanValue 'true''false
• StringKey 'op'
• StringValue 'eq 'ne 'lt 'gt
  'le 'ge 'range 're'

13
Less Restricted Syntax Examples

• Examples are explained in terms of
• Object matching
• Function execution
• Data return

14
Example 1

• ltGetNodeStategt
•   ltNodeStategt
•     ltNodegtccn22lt/Nodegt
•     ltAdminState match'false'/gt
•     ltState match'false'/gt
•   lt/NodeStategt
• lt/GetNodeStategt
• 1. All node state objects are matched where node
  'ccn22' adminstate and state can have any
  value.
• 2. Get functions are actually null operations
  that is, they don't actually modify matched
  objects or perform any object operations.
• 3. All fields included in the query are included
  in the response by default, so any matched
  objects are returned including fields node,
  adminstate, and state.
• Since there will only be one node-state element
  per node, and nodes are uniquely named, this
  query will yield either 0 or 1 response elements.
  The response will look like
• ltNodeStatesgt
•   ltNodeStategt
•     ltNodegtccn22lt/Nodegt
•     ltAdminStategtofflinelt/AdminStategt
•     ltStategtuplt/Stategt
•   lt/NodeStategt

15
Example 2

• ltDiagnose mode'online type'parallel'gt
•   ltNodeStategt
•     ltNode op're'gtccn\dlt/Nodegt
•      ltAdminState match'false'/gt
•     ltState return'false'gtuplt/Stategt
•   lt/NodeStategt
• lt/Diagnosegt
• 1. All node state objects are matched where node
  matches the regular expression "ccn\d". The
  state attribute must be "up". AdminState may have
  any value..
• 2. The diagnose function is executed on all
  matching node-state objects, with function
  arguments type (online) and parallel (true).
• 3. All attributes are returned, with the
  exception of State,.
• This return would look like
• ltNodeStatesgt
• ltNodeStategt
• ltNodegtccn1lt/Nodegt
• ltAdminStategtonlinelt/AdminStategt
• ltNodeState

16
Example 3

• ltSignalProcessGroup signal'SIGINT'
  scope'single'gt
•   ltProcessGroupgt
•     ltPGID match'false'/gt
•      ltUser match'false'/gt
•      ltProcessesgt
•        ltProcessgt
•            ltHostgtccn221lt/Hostgt
•           ltPid match'false'/gt
•       lt/Processgt
•       ltProcessgt
•           ltHost gtccn222lt/Hostgt
•           ltPid match'false'/gt
•       lt/Processgt
•    lt/Processesgt
•   lt/ProcessGroupgt
• lt/SignalProcessGroupgt
• 1. We are looking for process groups where there
  exists at least one process on ccn221 and ccn222.
  

17
Returns

• Returns a container of process groups, each
  containing processes with the information
  requested
• ltProcessGroupsgt
•   ltProcessGroupgt
• ltpgidgt2232lt/pgidgt
• ltusergtuser1lt/usergt
• ltProcessesgt
•       ltProcessgt
• lthostgtccn221lt/hostgt
• ltpidgt2232ltpid/gt
• lt/Processgt
•       ltProcessgt
• lthostgtccn222lt/hostgt
• ltpidgt2542lt/pidgt
• lt/Processesgt
•    lt/ProcessGroupgt
•    ltProcessGroupgt
• .
•    lt/ProcessGroupgt

18
Advantages of Changes to Restriction Syntax

• Retain High value of validation
• Can make validation do even more than with RS
• Gives up some conciseness to clean up overloading
  of attributes
• Clean negation

19
In Use

• We are currently changing the syntax recognized
  by several components to use this syntax.
• Build and config
• Process management (details tomorrow)
• Infrastructure components
• Needed Better name!

20
Notes