OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

csaf message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] (CSAF-27) non-substantial enhancement - note ordering requirements solely on the containers and not on the contained


     [ https://issues.oasis-open.org/browse/CSAF-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Hagen updated CSAF-27:
-----------------------------

    Description: 
We should as a non-substantial change (in an upcoming WD02) move all ordering constraints solely to the sections of the container elements and strip the ever so clunky ordering statements from the contained element requirements.

Especially since we have so many optional elements this does not help the reader at all but only doubles on statement volume without adding further precision, but instead adding the risk of inconsistencies or hardly parseable statements.

Besides the formal "service to the reader" and "optimal base selection for describing" there is another rationale (which for the reporter is of utmost importance among the three): Going format agnostic from an implementation specific model almost always has not one but two required steps to succeed before one can add "another" format: 

1. Extract the data model A from the specifics 

2. Triage the now domain specific implementation agnostic model A into: 

2.1 A.1 core requirements and rules

2.2 A.2 possibly real domain requirements that are representable / enforceable only by some of the considered implementation formats 

2.3 A.3 ballast from overshoot "because we *could* with format A" do things like that 

Based on this refactoring and triage efforts, with the three buckets then we can (as the suggested processing model): 

1. Toss any A.3 (or move to requirements on conforming implementation of the applicable formats i.e. A.2) or maybe pull parts upstream into the general reqs A.1 

2. Keep and further straighten the (resulting) requirements in A.1 maybe with the freshened set, some get pushed (partially) down into A.2 ...

3. Spend presumably some real work cycles on processing the (resulting) requirements from bucket A.2 to find the best fit place guided by the 2x2 matrix spanned by the dimensions cardinality(zero, one, more) and applicability(formats) 

*Note*: As important discussions off the CVSS v3 - "to enforce or not in v1.2" - question may deserve some time, and the editor has no practical opinion in this discussion plus the outcome of the discussion can easily be applied to the document, ... the reporting editor will use the time waiting for a settlement, to: 

Prepare a variant of the CSD01 WD01 containing the results of the step decoupling intra-container ordering requirements from the "my place among my siblings" statements of the contained elements. 

Thinking of JSON objects as possible containers with uniquely keyed members only - these container ordering statements are best isolated, as they mostly "smell" like A.3 candidates for above triage ...


  was:
We should as a non-substantial change (in an upcoming WD02) move all ordering constraints solely to the sections of the container elements and strip the ever so clunky ordering statements from the contained element requirements.

Especially since we have so many optional elements this does not help the reader at all but only doubles on statement volume without adding further precision, but instead adding the risk of inconsistencies or hardly parseable statements.

Besides the formal "service to the reader" and "optimal base selection for describing" there is another rationale (which for the reporter is of utmost importance among the three): Going format agnostic from an implementation specific model almost always has not one but two required steps to succeed before one can add "another" format: 

1. Extract the data model A from the specifics 

2. Triage the now domain specific implementation agnostic model A into: 

2.1 A.1 core requirements and rules

2.2 A.2 possibly real domain requirements that are representable / enforceable only by some of the considered implementation formats 

2.3 A.3 ballast from overshoot "because we *could* with format A" do things like that 

Based on this refactoring and triage efforts, with the three buckets then we can (as the suggested processing model): 

1. Toss any A.3 (or push down to requirements on conforming implementation of the applicable formats i.e. A.2) or maybe pull parts upstream into the general reqs A.1 

2. Keep and further straighten the (resulting) requirements in A.1 maybe with the freshened set, some get pushed (partially) down into A.2 ...

3. Spend presumably some real work cycles on processing the (resulting) requirements from bucket A.2 to find the best fit place guided by the 2x2 matrix spanned by the dimensions cardinality(zero, one, more) and applicability(formats) 

*Note*: As important discussions off the CVSS v3 - "to enforce or not in v1.2" - question may deserve some time, and the editor has no practical opinion in this discussion plus the outcome of the discussion can easily be applied to the document, ... the reporting editor will use the time waiting for a settlement, to: 

Prepare a variant of the CSD01 WD01 containing the results of the step decoupling intra-container ordering requirements from the "my place among my siblings" statements of the contained elements. 

Thinking of JSON objects as possible containers with uniquely keyed members only - these container ordering statements are best isolated, as they mostly "smell" like A.3 candidates for above triage ...



> non-substantial enhancement - note ordering requirements solely on the containers and not on the contained
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: CSAF-27
>                 URL: https://issues.oasis-open.org/browse/CSAF-27
>             Project: OASIS Common Security Advisory Framework (CSAF) TC
>          Issue Type: Task
>            Reporter: Stefan Hagen
>            Assignee: Stefan Hagen
>
> We should as a non-substantial change (in an upcoming WD02) move all ordering constraints solely to the sections of the container elements and strip the ever so clunky ordering statements from the contained element requirements.
> Especially since we have so many optional elements this does not help the reader at all but only doubles on statement volume without adding further precision, but instead adding the risk of inconsistencies or hardly parseable statements.
> Besides the formal "service to the reader" and "optimal base selection for describing" there is another rationale (which for the reporter is of utmost importance among the three): Going format agnostic from an implementation specific model almost always has not one but two required steps to succeed before one can add "another" format: 
> 1. Extract the data model A from the specifics 
> 2. Triage the now domain specific implementation agnostic model A into: 
> 2.1 A.1 core requirements and rules
> 2.2 A.2 possibly real domain requirements that are representable / enforceable only by some of the considered implementation formats 
> 2.3 A.3 ballast from overshoot "because we *could* with format A" do things like that 
> Based on this refactoring and triage efforts, with the three buckets then we can (as the suggested processing model): 
> 1. Toss any A.3 (or move to requirements on conforming implementation of the applicable formats i.e. A.2) or maybe pull parts upstream into the general reqs A.1 
> 2. Keep and further straighten the (resulting) requirements in A.1 maybe with the freshened set, some get pushed (partially) down into A.2 ...
> 3. Spend presumably some real work cycles on processing the (resulting) requirements from bucket A.2 to find the best fit place guided by the 2x2 matrix spanned by the dimensions cardinality(zero, one, more) and applicability(formats) 
> *Note*: As important discussions off the CVSS v3 - "to enforce or not in v1.2" - question may deserve some time, and the editor has no practical opinion in this discussion plus the outcome of the discussion can easily be applied to the document, ... the reporting editor will use the time waiting for a settlement, to: 
> Prepare a variant of the CSD01 WD01 containing the results of the step decoupling intra-container ordering requirements from the "my place among my siblings" statements of the contained elements. 
> Thinking of JSON objects as possible containers with uniquely keyed members only - these container ordering statements are best isolated, as they mostly "smell" like A.3 candidates for above triage ...



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]