I've noticed that a <p
class="conformance">
that includes nested lists isn't rendered correctly.
Servers
MUST implement,
and SHOULD
document, 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 <p
class="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 MAY
treat 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 MAY
treat 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 MAY
treat the literal in the same way as an XML literal string such as "abc"^^rdf:XMLLiteral.
[QUERY-26]
Servers MAY
validate the string for compliance to the XMLLiteral standard. [QUERY-27]
The
operators =,
!=,
and in
MUST be supported.
[QUERY-28]
Servers MUST
implement, and SHOULD
document, 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 MAY
choose which of the above to apply based on whether the string contains
a %
or _
character, and/or the property being compared. A server SHOULD
document if this is the case. [QUERY-30]
Other operators MAY
be supported and MAY
have implementation-dependent semantics. A server MAY
report 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 MAY
be supported and MAY
have implementation-dependent semantics. A server MAY
report such usage as unsupported.
Does that matter?
Best regards,
David
From:
"Jim Amsden"
<>
To:
"OASIS OSLC Core
TC Discussion List" <>
Date:
13/09/2018 16:31
Subject:
[oslc-core]
Adding conformance class markers
Sent by:
<>
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
