Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Media types other than vc+ld+json #1100

Closed
wants to merge 11 commits into from
Closed

Media types other than vc+ld+json #1100

Changes from 8 commits
Commits
Show all changes
11 commits
Select commit Hold shift + click to select a range
bb40d9d
initial text for additional media types
m00sey Apr 26, 2023
2d44d38
Merge branch 'w3c:main' into main
m00sey Apr 26, 2023
b527a69
Update index.html
m00sey Apr 26, 2023
7ab04db
Update index.html
m00sey Apr 28, 2023
0548973
Update index.html
m00sey Apr 28, 2023
6223061
Update index.html
m00sey Apr 28, 2023
06b1223
Update index.html
m00sey Apr 28, 2023
d191dc1
formatting
m00sey Apr 28, 2023
01eb7d0
Update index.html
m00sey May 1, 2023
3d6aa67
Update index.html
m00sey May 1, 2023
6bdf8e8
Update index.html
m00sey May 1, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
25 changes: 25 additions & 0 deletions index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3484,6 +3484,31 @@ <h3>Media Types</h3>
those other syntaxes to be transformed to the `application/vc+ld+json`
media type.
</p>

<p>
Additional media type transformation specifications can be
m00sey marked this conversation as resolved.
Show resolved Hide resolved
defined to provide implementers with further options for producing objects
m00sey marked this conversation as resolved.
Show resolved Hide resolved
that can be mapped to the base media type.
m00sey marked this conversation as resolved.
Show resolved Hide resolved
</p>
<p>
Specifications are registered with the [[?VC-SPECS]] and
MUST result in a transformed, concrete serialization
that is objectively testable via a conformance test suite.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's ambiguous what you're saying should be testable. Is it the transformed representation that is tested (in which case a VC Data Model test suite could be used). Or are you also asking for testing of the additional media type representation?

Copy link
Contributor

@selfissued selfissued Apr 28, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's also not clear to me what the "MUST result" language means. The day 3 resolution says that a transformation must exist. It doesn't say that particular deployments must use transformations.

Copy link
Contributor

@OR13 OR13 Apr 28, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more. 

Specifications are registered with the [[?VC-SPECS]] and
MUST result in a transformed, concrete serialization
that is objectively testable via a conformance test suite.

Informative reference, followed by a MUST feels a bit off here.

If this is guidance to the registry maintainers, to gate entries I think this goes against our intention to keep the "vc specs directory", lightweight and not a registry.

This sentence also goes beyond the day 3 resolution, which only required this level of rigor for representations defined by this working group, but this would apply to all registered entries in the informative note.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's ambiguous what you're saying should be testable. Is it the transformed representation that is tested (in which case a VC Data Model test suite could be used). Or are you also asking for testing of the additional media type representation?

The transformed representation should be testable against the VC Data Model test suite, yes.

Comment on lines +3494 to +3496
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would rather not have that requirement.

  • Does it mean we must have tests in the W3C Test Suite repo?
  • Or is it ok if the conformance tests are somewhere else?
  • What should those tests test, ie input file in the media type and then spitting out a JSON-LD VC?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What should those tests test, ie input file in the media type and then spitting out a JSON-LD VC?

Yes, that would at least point to some interop potential.
Every media type can at least "get to" the base media type.

Conceptually, the relationship between this (VCDM2.0) specification and a Media Type Representation specification (VC-JWT/Gordian/ACDC/Any) is similar to the relationship between DID-Core and a specific DID Method specification.

By defining a Media Type section we acknowledge there will be other media types wanting to be consumed as VCs, we should be defining a minimal number of steps/spec/transform that allows someone to produce something of the base media type and know it's going to be interoperable with others.

Happy to rework the language if its too constrained

</p>
<p>
Transformations from other media types MUST state the directionallity of the
transformation from the options:
</p>
<ul>
<li>Unidirectional</li>
<li>Bidirectional</li>
</ul>
<p>
Bidirectional transformations MUST result in a lossless round-trip conversion between
Copy link
Contributor

@OR13 OR13 Apr 28, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not testable, and the details matter regarding claims of "losslessness".

CBOR-LD conversions destroy field ordering, and can have weird interactions with date formats... It would probably be better to leave the details regarding what "bidirectional mapping" means, to the spec that defines it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

agree, without an example of how this could be tested we should remove it

the originating serialization and a resulting `application/vc+ld+json` serialization
that conforms to the data model in this specification.
</p>

</section>

<section>
Expand Down