Re: [oslc-core] Adding conformance class markers

["Jim Amsden" <jamsden@us.ibm.com>]

I would recommend refactoring the content to
apply class='conformance' to only that content you want to appear in the
conformance table. You don't need to include the whole complex clause.
The entry in the table is just a reference to the section in the spec.


Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575




From:      
 David Honey1 <DavidHoney@uk.ibm.com>
To:      
 "Jim Amsden"
<jamsden@us.ibm.com>
Cc:      
 "OASIS OSLC Core
TC Discussion List" <oslc-core@lists.oasis-open.org>
Date:      
 09/13/2018 01:27 PM
Subject:    
   Re: [oslc-core]
Adding conformance class markers
Sent by:    
   <oslc-core@lists.oasis-open.org>

---

I've noticed that a <pclass="conformance">that includes nested lists isn't rendered correctly.

Servers MUST implement, and SHOULDdocument, one of the following semantics: [QUERY-29]

• case sensitive string compare
• case insensitive string compare
• case insensitive string pattern match where %means match zero or more characters, and _means match any single character.

Even though the first sentence and unordered list are within <pclass="conformance">
...  <p>
only the first sentence is included
in the conformance. 

Is this easy to fix? 

The other thing is that currently the query spec uses a table for oslc.where
semantics. In the body of the document, these all make sense since the
2nd and 3rd column relate to the first column.

rdf:XMLLiteral

An XMLLiteral, such as "abc"^^rdf:XMLLiteral, MUST be supported. A server MAYtreat the literal in the same way as a plain string literal with the data type removed such as "abc". [QUERY-24] A plain string literal, such as "abc"MUST be supported. A server MAYtreat the literal in the same way as an XML literal string such as "abc"^^rdf:XMLLiteral. [QUERY-25] An xsd:string typed literal, such as "abc"^^xsd:string, MUST be supported. A server MAYtreat the literal in the same way as an XML literal string such as "abc"^^rdf:XMLLiteral. [QUERY-26] Servers MAYvalidate the string for compliance to the XMLLiteral standard. [QUERY-27]

The operators =, !=, and inMUST be supported. [QUERY-28] Servers MUSTimplement, and SHOULDdocument, one of the following semantics: [QUERY-29] case sensitive string compare case insensitive string compare case insensitive string pattern match where %means match zero or more characters, and _means match any single character. A server MAYchoose which of the above to apply based on whether the string contains a %or _character, and/or the property being compared. A server SHOULDdocument if this is the case. [QUERY-30] Other operators MAYbe supported and MAYhave implementation-dependent semantics. A server MAYreport such usage as unsupported. [QUERY-31]

However, in the conformance section, these are quoted out of context, so not very meaningfull.
For example:

QUERY-31

Other operators MAYbe supported and MAYhave implementation-dependent semantics. A server MAYreport such usage as unsupported.

Does that matter?

Best regards,
David




From:        "Jim Amsden" <jamsden@us.ibm.com>
To:        "OASIS OSLC Core TC Discussion List" <oslc-core@lists.oasis-open.org>
Date:        13/09/2018 16:31
Subject:        [oslc-core] Adding conformance class markers
Sent by:        <oslc-core@lists.oasis-open.org>

---

Here's my notes on how to update the OSLC core documents to mark conformance
clauses and generate the Conformance section.

We agreed to day that:
- Nick will cover Configuration Management and TRS documents
- David will cover OSLC Query
- Martin will do Discovery.
- Jim will do the rests (the TODO items that are unchecked below or Dialogs,
Core, Resource Preview, Resource Shapes)

When these are done, we can publish another committee specification and
determine if it needs another public review. 

Apply changes to all core documents to capture conformance clauses using
the new ReSpec feature.

â Add the following respecConfig parameter for the specification, e.g.,:
    conformanceLabelPrefix: "AT",

â Change sections representing conformance clauses to <p id=âââ
class='conformance'

â Add this section right before the first appendix (the content will be
generated):
<section id="conformance"></section>

â Make sure thereâs some conformance clause for the vocabulary and constraints.
Something like the following needs to be added if its not already there:

<p class='conformance'>An OSLC server providing the Attachments capability
MUST implement the vocabulary defined in this section.</p>

<p class='conformance'>An OSLC server providing the Attachments capability
MUST implement the Constraints defined in this section.</p>


       â        Attachments: has
an Implementation Conformance section and each requirement or possible
conformance clause is marked in  normalText headers.

â Add the following respecConfig parameter:
    conformanceLabelPrefix: "AT",

â Change sections such as:
       <section id="attachment_update_descriptor">
        <h2></h2>

           When servers update an attachment,
they MUST also update any
           affected <code>oslc:AttachmentDescriptor</code>
properties of the associated attachment descriptor.
       </section>

to:

       <p id="attachment_update_descriptor"
class="conformance">
           When servers update an attachment,
they MUST also update any
           affected <code>oslc:AttachmentDescriptor</code>
properties of the associated attachment descriptor.
       </p>

â Make sure thereâs some conformance clause for the vocabulary and constraints.
Something like the following needs to be added if its not already there:

<p class='conformance'>An OSLC server providing the Attachments capability
MUST implement the vocabulary defined in this section.</p>

<p class='conformance'>An OSLC server providing the Attachments capability
MUST implement the Constratints defined in this section.</p>

â Add this section right before the first appendix (the content will be
generated):

<section id="conformance"></section>

       â        Dialogs: has an
Implementation Conformance section and each requirement is marked in  
normalText headers.

       â        Discovery: marks
the requirements in normalText headers, but doesnât organize them in a
specific Implementation Conformance section. Martin will do these

       â        Core: marks the
requirements in normalText headers, but doesnât organize them in a specific
Implementation Conformance section. I already started this

       â        Resource Preview:
has an Implementation Conformance section and each requirement or possible
conformance clause is marked in  normalText headers.

       â        Resource Shapes:
has no conformance section and doesnât mark any conformance clauses or
rules. Only has normative sections and MUST, SHOULD, MAY requirements.

       â        Core Vocabulary:
has no conformance section and doesnât mark any conformance clauses or
rules. Only has normative sections and MUST, SHOULD, MAY requirements.

       â        Query: has no conformance
section and doesnât mark any conformance clauses or rules. Only has normative
sections and MUST, SHOULD, MAY requirements. David will do these

       â        TRS: has no conformance
section and doesnât mark any conformance clauses or rules. Only has normative
sections and MUST, SHOULD, MAY requirements. Nick will do these

       â        Config Management:
has no conformance section and doesnât mark any conformance clauses or
rules. Only has normative sections and MUST, SHOULD, MAY requirements.
Nick will do these

       â        Versioned Resources:
has no conformance section and doesnât mark any conformance clauses or
rules. Only has normative sections and MUST, SHOULD, MAY requirements.
Nick will do these

       â        Configuration Specification:
has no conformance section and doesnât mark any conformance clauses or
rules. Only has normative sections and MUST, SHOULD, MAY requirements.
Nick will do these

       â        RDF Vocabulary:
has no conformance section and doesnât mark any conformance clauses or
rules. Only has normative sections and MUST, SHOULD, MAY requirements.



Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU