Unfortunately, what you wrote in your source
HTML is not what you get in the browser - the browser added some </p>
and <p> tags implicitly! As per the HTML spec (see for example https://www.w3.org/TR/html/grouping-content.html#the-p-element):
List elements (in particular, ol and
ulelements) cannot be children of pelements. When a sentence contains a bulleted list, therefore, one might
wonder how it should be marked up.
For instance, this fantastic
sentence has bullets relating to
â wizards,
â faster-than-light travel,
and
â telepathy,
and is further discussed
below.
The solution is to realize that a paragraph,
in HTML terms, is not a logical concept, but a structural one. In the fantastic
example above, there are actually five paragraphsas defined by this specification: one before the list, one for each bullet,
and one after the list.
Authors wishing to conveniently style
such "logical" paragraphs consisting of multiple "structural"
paragraphs can use the divelement instead of the p element.
However, I would caution against putting
entire large blocks of text in the conformance clauses unless you write
your own conformance summary and use the noConformanceTable:
1 setting in your config section,
otherwise the conformance table may get too large to be readable. The 'accident'
of using only the first part of your conformance block here may be a happy
one!
Nick.
From:
David Honey1 <>
To:
"Jim Amsden"
<>
Cc:
"OASIS OSLC Core
TC Discussion List" <>
Date:
09/13/2018 10:27 AM
Subject:
Re: [oslc-core]
Adding conformance class markers
Sent by:
<>
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:XMLLiteralAn
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-31Other
operators MAYbe supported and MAYhave implementation-dependent semantics. A server MAYreport 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
