Profile Resolution 1.0.2 Updates #1172
Conversation
stephenbanghart
force-pushed
the
release-1.0
branch
from
5135bd8
to
8e58819
Compare
src/specifications/profile-resolution/profile-resolution-specml.xml
Outdated
Show resolved
Hide resolved
src/specifications/profile-resolution/profile-resolution-specml.xml
Outdated
Show resolved
Hide resolved
| <li><p><req level="must" id="req-internal-resolve3">When a <src>rlink</src> is encountered and is to be resolved, it MUST be resolved by using a HTTP Client request to retrieve a Byte Stream. </req></p> </li> | ||
| <li><p><req level="must" id="req-internal-resolve4">When a <src>base64</src> is encountered and is to be resolved, it MUST be considered a Byte Stream.</req> </p> </li> | ||
| <li><p><req level="must" id="req-internal-resolve5">Regardless of its source, the Byte Stream MUST be decoded based on the algorithm defined in <a href="https://datatracker.ietf.org/doc/html/rfc4648"> Section 4 RFC 4648</a>. </req></p> </li> | ||
| </ul> |
There was a problem hiding this comment.
These are wonderful additions, thanks Stephen! One that was discussed in general discussion of this work during the weekly Thursday status meeting was how explicit to be about processing the @media-type of the back-matter resource. Did you, Dave, and Wendell decide it was best to leave this out of the spec?
There was a problem hiding this comment.
Providing strict requirements around it may be difficult, but some prose giving recommendations would probably be valuable.
There was a problem hiding this comment.
I'm cool either way, I didn't know it was important to the requirements of the spec around the requirements, explicit or implict, for #1140. Since we will talk this over in the meeting in a few minutes, I am definitely ok with resolving and withdrawing the question.
I know it came up last week around this point: I didn't know what the result of the conversation about it was. I defer to Dave and Wendell about not being explicit.
src/specifications/profile-resolution/profile-resolution-specml.xml
Outdated
Show resolved
Hide resolved
src/specifications/profile-resolution/profile-resolution-specml.xml
Outdated
Show resolved
Hide resolved
Co-authored-by: Alexander Stein <[email protected]>
* Specification changes, #1141 #1142 #1155 * Mapping documentation, UUID RFC reference * Apply suggestions from AJ's review Co-authored-by: Stephen Banghart <[email protected]> Co-authored-by: Alexander Stein <[email protected]>
* Specification changes, usnistgov#1141 usnistgov#1142 usnistgov#1155 * Mapping documentation, UUID RFC reference * Apply suggestions from AJ's review Co-authored-by: Stephen Banghart <[email protected]> Co-authored-by: Alexander Stein <[email protected]>
* Specification changes, usnistgov#1141 usnistgov#1142 usnistgov#1155 * Mapping documentation, UUID RFC reference * Apply suggestions from AJ's review Co-authored-by: Stephen Banghart <[email protected]> Co-authored-by: Alexander Stein <[email protected]>
Addresses:
#1141
Enhanced prose around Group handling, especially around expected behavior of the "keep always" prop.
#1142
Core issue obsoleted by general OSCAL requirements on valid OSCAL documents. Cleaned up prose in the formats section.
#1155
Fixed incorrect notation in metadata section: props are now properly refereed to as such, rather than using the value of their "name" field.
#1140
Significant improvements around resolution of internal references. Behavior is now defined for resolving resources with different combinations of "rlink" and "base64". As these /should/ all be equal to one another, there is no standardized order or priority given in the specification at this time.
#1152
Added Metaschema entries for the new Mapping assembly and it's associated fields/flags. Verified the veracity of existing Profile documentation, making minor-moderate edits to bring documentation up to speed with the current specification.