[ogsa-bes-wg] BES spec

[Christopher Smith]

Another rendering for this, which Marvin and I explored a little bit when
writing our document, is:

<ActivityState BaseState="running">
    <SubState StateName="profile1:Stagingin>
        <SubState StateName="profile1:Held"/>
    </SubState>
</ActivityState>

It would also be nice to support being in multiple sub states (if it makes
sense) because of various profiles and operations, so if (for example) I was
in the above state, but the user also suspended the job, I could be in:

<ActivityState BaseState="running">
    <SubState StateName="profile1:Stagingin>
        <SubState StateName="profile1:Held"/>
    </SubState>
    <SubState StateName="profile2:Suspended"/>
</ActivityState>

By representing the actual state as the name of these State/SubState
elements, then even a client that doesn't understand the sub states can
parse the state element (because everything understands "ActivityState" and
"SubState". The BaseState values come from an enumeration, since they are
well known, and the StateName values are prefixed with the namespace of the
profile they are defined in.

-- Chris


On 03/7/06 03:08, "David Snelling" <David.Snelling at UK.Fujitsu.com> wrote:

> Karl,
> 
> To be complete your example would ned to be:
> 
> <Running>
>     <Stagingin>
>        <Held/>
>     </Stagingin>
> </Running>
> 
> Right?
> 
> I need to think more about this, but it may be ok.
> 
> Could we standardize the meaning of some of the substates, such as
> <Held/> and <Suspended/>? Then we could get standardized semantics
> anywhere. E.g.
> 
> <bes;Running>
>     <ds:DavesSpecialDataMovementState>
>        <bes:Held/>
>     </ds:DavesSpecialDataMovementState>
> </bes:Running>
> 
> 
> 
> On 3 Jul 2006, at 08:42, Karl Czajkowski wrote:
> 
>> On Jul 03, David Snelling modulated:
>> 
>>> There is one thing I am concerned about and that is how do we express
>>> these substates? For example we want to be able to combine the
>>> concepts of StagingIn and Held without building a complex matrix of
>>> all possible combinations. While at the same time, we want
>>> StagingIn_Held to be a substate of StagingIn and restricted
>>> accordingly, e.g. limiting what the next states can be. What does
>>> this look like in XML?
>> 
>> Maybe it shouldn't be StagingIn_Held, it should be /StagingIn/Held
>> (using XPath syntax):
>> 
>>   <stagingIn>
>>      <held/>
>>   </stagingIn>
>> 
>> come on, the answer is right there in the phrase "NESTED states". ;-)
>> 
>> The advantage here is you can use open extensibility (with the "any
>> other" namepsace restriction, perhaps) to allow anyone to define
>> extensions. As you mentioned, a client can ignore the inner (extended)
>> content if they wish to operate more generically.
>> 
>> I agree with your explanation of state transition rules. Note, this is
>> just rephrasing the theory of hypergraphs, so people could look to
>> that for references if they are worried about the ramifications.
>> 
>> 
>> karl
>> 
>> -- 
>> Karl Czajkowski
>> karlcz at univa.com