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 meeting’s 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:1. Identification of sets of objects

• Or construction

2. Specification of function (with arguments)3. 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

<get-node-state>

<node-state node=‘ccn22’ adminstate=‘*’ state=‘*’ />

</get-node-state>

Becomes

<GetNodeState>

<NodeState>

<Node>ccn22</Node>

<AdminState match=‘false’ />

<State match=‘false’ />

</NodeState>

</GetNodeState>

10

LRS BNF

[InMsg] ::= <[Command] [Arguments]> [Specification] </[Command]>

[Command] ::= [identifier]

[Arguments] ::= [] | [Argument] | [Argument] [Arguments]

[Argument] ::= [identifier]=[identifier]

[identifier] ::= [letter] | [letter] [identifier]

[OutMsg] ::= <[ContainerName]> [Objects] </ContainerName>

[Objects] ::= [ ] | [Object] | [Object] [Objects]

11

Specifications

[Specification] ::= [ObjectDescription] | [ObjectDescription] [Specification] (must match one or more)

[ObjectDescription] ::= <[ObjectName]> [ObjectDetails] </[ObjectName][ObjectName] ::= [identifier]

[ObjectDetails] ::= [Field] | [Field] [ObjectDetails] |                     [MultiField] | [MultiField] [ObjectDetails]

[Field] ::= <[FieldName]> [FieldValue] </[FieldName]> |                 <[FieldName] [Qualifiers]> [FieldValue] </[FieldName]>

[MultiField] ::= <[Container]>[MFields]</Container>[MFields] ::= [MField]|[MField][MFields][MField] ::= [Field]

12

Qualifiers

[FieldName] ::= [identifier]

[Qualifiers] ::= [] | [Qualifier] [Qualifiers]

[Qualifier] ::= [BooleanKey]=[BooleanValue] |

[StringKey]=[StringValue]

[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

1.Object matching2.Function execution3.Data return

14

Example 1

<GetNodeState>  <NodeState>    <Node>ccn22</Node>    <AdminState match='false'/>    <State match='false'/>  </NodeState></GetNodeState>

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:

<NodeStates>  <NodeState>    <Node>ccn22</Node>    <AdminState>offline</AdminState>    <State>up</State>  </NodeState></NodeStates>

15

Example 2

<Diagnose mode='online‘ type='parallel'>  <NodeState>    <Node op='re'>ccn\d+</Node>     <AdminState match='false'/>    <State return='false'>up</State>  </NodeState></Diagnose>

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:

<NodeStates> <NodeState> <Node>ccn1</Node> <AdminState>online</AdminState> <NodeState …<NodeStates>

16

Example 3

<SignalProcessGroup signal='SIGINT' scope='single'>  <ProcessGroup>    <PGID match='false'/>     <User match='false'/>     <Processes>       <Process>           <Host>ccn221</Host>          <Pid match='false'/>      </Process>      <Process>          <Host >ccn222</Host>          <Pid match='false'/>      </Process>   </Processes>  </ProcessGroup></SignalProcessGroup>

1. We are looking for process groups where there exists at least one process on ccn221 and ccn222.

2. The function signal-process-group, with the arguments signal=SIGINT  and scope='single', is applied to each matched process-group  object. 

3. The pgid and user fields for each process group are returned,  along with hostname and pids for each of the processes on ccn221 or ccn222 in all the process groups that match.

17

ReturnsReturns a container of process groups, each containing processes with the information

requested:

<ProcessGroups>  <ProcessGroup> <pgid>2232</pgid> <user>user1</user> <Processes>      <Process> <host>ccn221</host> <pid>2232<pid/> </Process>      <Process> <host>ccn222</host> <pid>2542</pid> </Processes>   </ProcessGroup>   <ProcessGroup> ….   </ProcessGroup></ProcessGroups>

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