Skip to content

# Switch to array-based format - #13

Open
brianorwhatever wants to merge 1 commit into
w3c-ccg:mainfrom
aviarytech:main
Open

# Switch to array-based format#13
brianorwhatever wants to merge 1 commit into
w3c-ccg:mainfrom
aviarytech:main

Conversation

@brianorwhatever

Copy link
Copy Markdown

Changes the CEL data model to use arrays instead of objects at the root level. This makes the format simpler and better matches how event logs actually work.

Key changes:

  • Root structure is now an array instead of {log: [...]}
  • previousLog is now an event type rather than a property
  • Updated examples and docs to match

Before:

{
  "log": [{
    "event": {...},
    "proof": [...]
  }]
}

After:

[{
  "event": {...},
  "proof": [...]
}]

This should make the format easier to work with, especially for streaming. It also means everything (including previousLog) is just an event, which simplifies processing.

Closes #3

Changes the CEL data model to use arrays instead of objects at the root level. This makes the format simpler and better matches how event logs actually work.

Key changes:
- Root structure is now an array instead of {log: [...]}
- previousLog is now an event type rather than a property
- Updated examples and docs to match

Before:
```json
{
"log": [{
"event": {...},
"proof": [...]
}]
}
```

After:
```json
[{
"event": {...},
"proof": [...]
}]
```

This should make the format easier to work with, especially for streaming. It also means everything (including previousLog) is just an event, which simplifies processing.

Closes w3c-ccg#3
@dlongley

dlongley commented Jan 15, 2025

Copy link
Copy Markdown
Collaborator

I think there's disagreement on whether the root file should contain an object or an array and perhaps undiscussed pros/cons, but that disagreement might be resolvable by having the root file be a metadata-only file that doesn't include the log itself but a reference to the (most recent) log file -- and that log file would have the above array at the root level. That, or two well-known filenames can be defined in the spec.

This approach might also allow for expressing version / log format information, etc. What cryptographic proof(s) are on the metadata file is another consideration as well as whether it's worth the complexity.

There seems to me to be complexity in both directions so trade offs need more enumeration and consideration -- and it might be that it needs to be optional at this core spec level with specific applications making a particular choice.

@brianorwhatever

Copy link
Copy Markdown
Author

What cryptographic proof(s) are on the metadata file is another consideration as well as whether it's worth the complexity.

The complexity of this is my major concern. I believe any metadata required can and should be reworked into an event in the log. That way you know when it happened and it is verified in the same way other events are.

@dlongley

Copy link
Copy Markdown
Collaborator

@brianorwhatever,

The complexity of this is my major concern. I believe any metadata required can and should be reworked into an event in the log. That way you know when it happened and it is verified in the same way other events are.

I share this concern. I'm not yet convinced we've covered all the pros/cons though to get a fuller view of whether having a single file format that always has a top-level array is obviously better than some alternative.

@brianorwhatever

Copy link
Copy Markdown
Author

yep, this is just a strawman PR. Looking forward to enumerating the pros/cons

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Consider Using JSON Lines format

2 participants