How about REQUEST_RELATIVE? request and ground activity allow steps with time relation relative to the START_TIME of the request. Similar to BLOCK_RELATIVE.

@tloreilly56 does BLOCK_RELATIVE have a different existing meaning? The intent is for BLOCK_RELATIVE to be a generalization of SASF FROM_REQUEST_START.

I assume BLOCK_RELATIVE is equivalent to FROM_ACTIVITY_START, which is the start of the ground block. FROM_REQUEST_START is relative to the start of the request. Suppose in a request you have two ground activities and the steps within each activity have references to FROM_ACTIVITY_START. The relative time of FROM_ACTIVITY_START is different within each activity, each relative to the start of the two ground blocks in the expansion.

Aha, thank you. As I understand, SeqJSON doesn't support activities, so a SeqJSON request may only have a flat list of steps and that wouldn't apply unless we added activities. So maybe the question is, do we ever need SeqJSON to support activity expansion? I'm inclined to say no, but maybe it should?

@cartermak got it. If activity is not going to be supported in seq.json, we don't need to support a time type relative to the activity. For request, we need a time type relative to request start. Naming it REQUEST_START may be less confusing and have BLOCK_START available for later when activity is supported.

@tloreilly56 Why not use BLOCK_RELATIVE for request now and also be able to use it for activity later if we need to? I don't think we would ever be in a context where are activities and requests, so BLOCK_RELATIVE can mean the start of the request if it's in a request, the start of an activity if it's in an activity, and the start of a sequence if it's in a sequence but not inside a request (like satf). Agree with Carter that I don't expect us to ever support activity block types in seq json, though.

I understand we never expect to support activity block in seq.json. However, a request in seq.json can have a ground_block step which refers to a ground activity outside seq.json. That ground activity can have FROM_ACTIVITY_START or FROM_REQUEST_START time tag in the steps. I think using BLOCK_RELATIVE for steps in requests to refer to the start of the request is confusing.

@tloreilly56 The idea is that we can use BLOCK_RELATIVE as a general time tag to capture any time of time tag where the step should be issued relative to its container. The container could be an activity, a request, a sequence, etc. but BLOCK_RELATIVE can be used the same way in each case. In other words, how BLOCK_RELATIVE is used will depend on the context in which it is used. The issue is that if we use REQUEST_RELATIVE, then REQUEST_RELATIVE can only be a valid time tag within request types, and trying to enforce that REQUEST_RELATIVE can only be used for steps inside requests is going to complicate the schema. So we're trying to use a generalized time tag that for now is only going to be used for FROM_REQUEST_START but later could be used for other, similar types of time tags that may come up.

More generally, I would like to move away from having everything in SEQ JSON be 1:1 with what was in SATF/SASF

Does that make sense?

In your example, the request would only have a call to a ground block step, and the ground block would be entirely separate, so BLOCK_RELATIVE should have two distinct meanings in both cases. Also, as you pointed out, we do not plan to support ground blocks in seq json. So the meaning of BLOCK_RELATIVE in seq json should always be clear.

@shaheerk94 what I was trying to point out is in a ground block you could have a time tag relative to start of the block (BLOCK_RELATIVE) or relative to the start of the request (REQUEST_RELATIVE) that calls the block. Yes, in the request, you could use BLOCK_RELATIVE to represent the start of the request. I just think user might find it confusing using the term BLOCK_RELATIVE to represent relative to the start of request.

Attendees

@shaheerk94
@parkerabercrombie
@dandelany
@tloreilly56
@cartermak

Minutes

• In SEQ 2.0, we aren't carrying forward all existing terminology. SEQ 2.0 doesn't have a meaning to "block" outside VML, so here it could mean just a chunk of commands - sequence, request, ground block, etc.
• SeqJSON doesn't support definition of ground blocks, but you can call a ground block. So there could be ambiguity in the event of nested blocks where the "block" from which start time is being referenced is unclear.
• A ground block definition (from outside SeqJSON) can have a time tag which means something different than what we're proposing it means in SeqJSON. That time tag in SATF would be FROM_ACTIVITY_START, which is colloquially understood to mean "from the start of this block".
• We don't need to preserve terminology from legacy formats necessarily.
• We aren't changing the existing understanding of "block relative", we're just extending it to apply to requests.
• Seqgen does have an existing meaning of "block", and it doesn't include requests. So this does constitute more of a breaking change in the Seqgen context, even if the term isn't well-established in SeqJSON.
• Takeaway: disagreement is purely with overloading "block". Group is in agreement that we can have a time tag which means "relative to the start of this execution context", be it request, sequence, block, etc. We want something like "container relative", although it would be nice to have an initialism that's distinct from our existing time types (A, C, E, R). Other ideas: parent-relative, batch-relative, nested-relative, scope-relative, local-relative. "Parent" could be mis-interpreted as referencing the calling entity (e.g., parent sequence). D, T, P prefer "scope-relative", but leaving the door open to other suggestions.
• Next steps: mull over exact terminology, then update PR and request PMC approval.
• Side Q: What is a block? Both requests and blocks can contain logic and commands, but requests are higher-level than blocks.
• Side Q: How to time request steps relative to a specific epoch? Currently, we can only do this in SeqJSON when timing the request start. Some users may want to define the values for epochs in their sequence files too (heritage from SASF).

Some examples to describe the time type behavior.

This first example shows how multiple block-relative steps in an absolute-timed request would be evaluated:

{
    "id": "example",
    "metadata": {},
    "requests": [
        {
            "description": "This is a request",
            "name": "test_request_1",
            "steps": [
                {
                    "description": "This command executes 10s after the request start at 2020-001T00:00:10",
                    "args": [],
                    "time": {
                        "type": "BLOCK_RELATIVE",
                        "tag": "00:00:10"
                    },
                    "stem": "CMD_NO_OP",
                    "type": "command"
                },
                {
                    "description": "This note is evaluated 20s after the request start at 2020-001T00:00:20",
                    "string_arg": "Note Test.",
                    "time": {
                        "type": "BLOCK_RELATIVE",
                        "tag": "00:00:20"
                    },
                    "type": "note"
                },
                {
                    "description": "This command executes 30s after the request start at 2020-001T00:00:30",
                    "args": [],
                    "time": {
                        "type": "BLOCK_RELATIVE",
                        "tag": "00:00:30"
                    },
                    "stem": "CMD_NO_OP",
                    "type": "command"
                }
            ],
            "time": {
                "tag": "2020-001T00:00:00",
                "type": "ABSOLUTE"
            },
            "type": "request"
        }
    ]
}

This second example shows how the timing of these sequence steps would depend on modeling context of the sequence (I'm not sure there's any heritage for this pattern, but one could imagine the modeling software resolving these times to, e.g., absolute time tags for commands):

{
    "id": "mixed time types",
    "metadata": {},
    "steps": [
        {
            "description": "This command executes at 2020-001T00:00:00",
            "args": [],
            "time": {
                "type": "ABSOLUTE",
                "tag": "2020-001T00:00:00"
            },
            "stem": "CMD_NO_OP",
            "type": "command"
        },
        {
            "description": "This command executes 10s after the sequence start",
            "args": [],
            "time": {
                "type": "BLOCK_RELATIVE",
                "tag": "00:00:10"
            },
            "stem": "CMD_NO_OP",
            "type": "command"
        },
        {
            "description": "This command executes after the previous command completes",
            "args": [],
            "time": {
                "type": "COMMAND_COMPLETE"
            },
            "stem": "CMD_NO_OP",
            "type": "command"
        },
        {
            "description": "This command executes 30s after the previous command start",
            "args": [],
            "time": {
                "type": "COMMAND_RELATIVE",
                "tag": "00:00:30"
            },
            "stem": "CMD_NO_OP",
            "type": "command"
        },
        {
            "description": "This command executes 1h after the sequence start",
            "args": [],
            "time": {
                "type": "BLOCK_RELATIVE",
                "tag": "01:00:00"
            },
            "stem": "CMD_NO_OP",
            "type": "command"
        }
    ]
}