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

Add representation language to address syntax and "unknown" properties. #454

Merged
merged 3 commits into from Dec 1, 2020
Merged

Add representation language to address syntax and "unknown" properties. #454

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
36015b4
Add representation language to address syntax and "unknown" properties.
dlongley Nov 8, 2020
45c9131
Slight consumer/producer language tweak for clarity.
dlongley Nov 8, 2020
35e6c03
Apply suggestions from @jricher to address concerns from @selfissued …
msporny Dec 1, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
67 changes: 36 additions & 31 deletions index.html
View file
Open in desktop
Expand Up @@ -2328,6 +2328,29 @@ <h1>Representations</h1>
through the content of the <a>DID document</a> alone.
</p>

<p>
Unrecognized properties MUST be preserved. An unrecognized property is
any property that does not have explicit processing rules known to the consumer or producer.
Consumers MUST add all properties that do not have explicit processing rules
msporny marked this conversation as resolved.
Show resolved Hide resolved
for the representation being consumed to the abstract data model using only the
representation's generic type processing rules. Producers MUST serialize all
Copy link
Contributor

Choose a reason for hiding this comment

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

The Abstract Data Model is too Abstract. We need to make this more concrete before enforcing the MUST.

Copy link
Member

Choose a reason for hiding this comment

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

I think we did that with #455

properties in the abstract data model that do not have explicit processing
rules for the representation being produced using only the representation's
generic type processing rules.
</p>

<p class="note" title="Representation-specific syntax properties">
Note that properties that contain representation-specific syntax will only
have special processing rules defined by a single representation. Consumers of
a different representation are required to include these properties in
the abstract data model using only their generic type processing rules
to enable lossless conversion of representations. Similarly, producers
are required to treat properties containing representation-specific syntax
using generic type processing rules when producing a representation for which
the property is not defined. Representations are required to define producer
behavior for any such properties defined by the representation.
</p>

<p>
The production and consumption rules in this section apply to all
implementations seeking to be fully compatible with independent implementations
Expand Down Expand Up @@ -2361,6 +2384,11 @@ <h2>Representation Requirements</h2>
are conformant with the fragment processing rules defined in section
<a href="#fragment"></a> of this specification.
</li>
<li>
The representation MAY define representation-specific syntax that can
be stored as properties in the abstract data model. These properties are
included when consuming or producing to aid in ensuring lossless conversion.
</li>
</ol>
<p>
In order to maximize interoperability, representation specification authors
Expand Down Expand Up @@ -2493,12 +2521,6 @@ <h3>Production</h3>
to the value representation rules in the list above.
</p>

<p>
The member name <code>@context</code> MUST NOT be used as this property is
reserved for JSON-LD producers.
</p>


</section>

<section>
Expand Down Expand Up @@ -2612,22 +2634,9 @@ <h3>
data-cite="INFRA#convert-a-json-derived-javascript-value-to-an-infra-value">JSON
consumption rules</a> in the [[INFRA]] specification.
</p>

<p>
The value of the <code>@context</code> object member MUST be ignored as this is
reserved for JSON-LD consumers.
Comment on lines -2617 to -2618
Copy link
Contributor

Choose a reason for hiding this comment

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

Please replace the text above with that approved in the resolution https://www.w3.org/2019/did-wg/Meetings/Minutes/2020-11-05-did#resolution2 : "Note that the value of the @context object member will be ignored, if present."

Copy link
Member

Choose a reason for hiding this comment

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

This suggestion may address this concern: #454

Note that the value of the <code>@context</code> object member will be ignored, if present. That is, this field will not have additional processing applied to its value and will be added verbatim to the abstract data model.
</p>

<p>
Unknown object member names MUST be ignored as unknown properties.
Copy link
Contributor

Choose a reason for hiding this comment

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

Please replace the deleted text above with the text of the resolution https://www.w3.org/2019/did-wg/Meetings/Minutes/2020-11-03-did#resolution2 : "Unrecognized properties MUST be preserved." If this is not the right place, then put it somewhere else. But the text of the approved resolution needs to normatively appear in the spec.

Copy link
Member

Choose a reason for hiding this comment

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

I think the spirit of that resolution may be captured by this text, which is proposed above:

Consumers MUST add all properties that do not have explicit processing rules
for the representation being consumed to the abstract data model using only the
representation's generic type processing rules. Producers MUST serialize all
properties in the abstract data model that do not have explicit processing
rules for the representation being produced using only the representation's
generic type processing rules.

Copy link
Member

Choose a reason for hiding this comment

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

I believe this suggestion addresses your concerns: #454

</p>

<p class="issue" data-number="205">
This specification needs to define clear and consistent rules for how to handle
unknown data members on consumption, and this section needs to be updated with
that decision.
</p>

</section>

</section>
Expand Down Expand Up @@ -2691,7 +2700,13 @@ <h3>

<p>
The <a href="https://www.w3.org/TR/json-ld11/#the-context">JSON-LD
specification</a> defines values that are valid for this property.
specification</a> defines values that are valid for this property. This
property contains representation-specific syntax and therefore could
be present in the abstract data model to aid in lossless conversion. If
the property is present in the abstract data model, it MUST be used
during production unless either an alternative <code>@context</code> value is
explicitly provided to the producer or if the value from the abstract data
model is not valid according to the consumption rules.
dlongley marked this conversation as resolved.
Show resolved Hide resolved
</p>

<p>
Expand Down Expand Up @@ -2780,16 +2795,6 @@ <h3>
</dd>
</dl>

<p>
Unknown object member names MUST be ignored as unknown properties.
</p>

<p class="issue" data-number="205">
This specification needs to define clear and consistent rules for how to handle
unknown data members on consumption, and this section needs to be updated with
that decision.
</p>

<p>
Consumers SHOULD drop all properties from a <a>DID document</a> that are not
defined via the <code>@context</code>.
Expand Down