This is the abstract for your specification. It should be fairly short...a couple of sentences.
A simple introduction. It would be good if the reader ended the introduction knowing what the spec does, ideally including a simple key example.
Call out some key problems, use cases, scenarios that have motivated this specification. References are good, especially to some Use Cases and Requirements.
Terminology is based on OSLC Core Overview [[OSLCCore3]], W3C Linked Data Platform [[LDP]], W3C's Architecture of the World Wide Web [[WEBARCH]], and Hyper-text Transfer Protocol [[HTTP11]].
Optional section, though could be useful if intro can't cover it and you have enough concepts that it is worth elaborating on. A reasonable example is the JSON-LD Syntax spec.
Describe here any RDF namespaces defined by this standard, and their recommended prefixes. Also describe any other RDF namespace prefixes used in examples.
OSLC XXX servers MUST conform to [[!OSLCCore2]], and SHOULD conform to [[!OSLCCore3]] (and hence [[!LDP]]).
Add here any requirements for conformance to other standards.
The following table summarizes the conformance requirements for OSLC XXX.
The title of this section is flexible. Since the title of this spec should match what it does, it may not make sense to repeat it here. This section is intended to capture the conformance clauses (ie, the 'meat' of the spec).
Give your section title/id something meaningful and simple, don't include the actual section number.
Writing conformance clauses/statements: Create individual sections for each conformance clause. Each clause should cleanly map to a test case, see [[LDP]] spec and LDP testsuite for an example of this model.
OSLC specifications MUST provide [[RFC2116]] keywords that SHOULD be in ALL CAPS and MAY include client and/or server needs.
It is RECOMMENDED that OSLC specifications include examples whenever possible.
For every resource that is defined, define a shape for it. You may have additional shapes for certain scenarios. Shapes are published separately as Turtle files; you may have one shape per Turtle source file, or put several related shapes in one file; either way, you must have one data-include for each shape, using the right anchor URL.
Like first shape, included in same file, reusing some property definitions.
This section details how OSLC clients can discover this capability. It should follow the model set by [[LDP]] and [[OSLCCore3]]. Depending on the capability, it could be defined using existing HTTP headers, HTTP OPTIONS response, content in responses such as a predicate that links a ldp:Container to some other kinds of resource (such as type URL or shape), and so on.
Each specification may define new vocabulary terms. These should be defined with consideration for global use (not within a specific type of resource). Other domains and resource types will be encouraged to reuse these.
Call all key contributors, reviewers or general groups as needed.
Many thanks to Tim Berners-Lee for inventing the Web.
The change history is up to the editors to insert a brief summary of changes, ordered by most recent changes first and with heading from which public draft it has been changed from.