Recent documentation changes

spec/src/main/asciidoc/annotations.adoc

@@ -350,4 +350,4 @@ private DocumentRepository repositoryA;
 private DocumentRepository repositoryB;
 ----
 
-A producer method annotaded with the same `@Database` values must exist as well.
+A producer method annotated with the same `@Database` values must exist as well.

spec/src/main/asciidoc/jakarta_nosql_spec.adoc

@@ -31,15 +31,15 @@ include::license-alv2.asciidoc[]
 
 Jakarta NoSQL is a Java framework that streamlines the integration of Java applications with NoSQL databases. It defines a set of APIs and provides a standard implementation for most NoSQL databases. This clearly helps to achieve very low application coupling with the underlying NoSQL technologies used in applications.
 
-The project has two layers that define communication with NOSQL databases through API's. There are:
+The project has two layers that define communication with NoSQL databases through API's. These are:
 
 1. *Communication Layer*: Contains four modules, one for each NoSQL database type: Key-Value, Column Family, Document and Graph.
-Compared with traditional the RDBMS world, they are like the JDBC API.
+In the traditional the RDBMS world, this layer may be compared to the JDBC API.
 
-2. *Mapping Layer*: This layer is annotation-driven and uses technologies like CDI and Bean Validation, making it simple for developers to use.
-In the traditional RDBMS world, this layer can be compared to the Java Persistence API or object-relational mapping frameworks such as Hibernate.
+2. *Mapping Layer*: This layer is annotation-driven and uses technologies like Jakarta Contexts and Dependency Injection and Jakarta Bean Validation, making it simple for developers to use.
+In the traditional RDBMS world, this layer may be compared to the Java Persistence API or object-relational mapping frameworks such as Hibernate.
 
-Jakarta NoSQL has one API for each NoSQL database type. However, it uses the same annotations to map Java objects.
+Jakarta NoSQL defines an API for each NoSQL database type. However, it uses the same annotations to map Java objects.
 Therefore, with just these annotations that look like JPA, there is support for more than twenty NoSQL databases.
 
 [source,java]
@@ -57,27 +57,37 @@ public class Deity {
 }
 ----
 
-Vendor lock-in is one of the things any Java project needs to consider when choosing NoSQL databases. If there's a need for a switch, other considerations include: time spent on the change, the learning curve of a new API to use with this database, the code that will be lost, the persistence layer that needs to be replaced, etc. Jakarta NoSQL avoids most of these issues through the Communication APIs. It also has template classes that apply the design pattern 'template method’ to databases operations. And the Repository interface allows Java developers to create and extend interfaces, with implementation automatically provided by a Jakarta NoSQL implementation: support method queries built by developers will automatically be implemented for them.
+Vendor lock-in is one of the things any Java project needs to consider when choosing NoSQL databases. If there is a need to switch out a database, other considerations include: time spent on the change; the learning curve of a new database API; the code that will be lost; the persistence layer that needs to be replaced, etc. Jakarta NoSQL avoids most of these issues through the Communication APIs. It also has template classes that apply the design pattern 'template method’ to databases operations. And the `Repository` interface allows Java developers to create and extend interfaces, with implementation automatically provided by a Jakarta NoSQL implementation: support method queries built by developers will automatically be implemented for them.
 
 [source,java]
 ----
 public interface DeityRepository extends Repository<Deity, String> {
 
+    Optional<Deity> findById(String id);
     Optional<Deity> findByName(String name);
 
 }
+----
+[source,java]
+----
+SeContainer container = SeContainerInitializer.newInstance().initialize()
+
+Service service = container.select(Service.class).get();
+
+DeityRepository repository = service.getDeityRepository();
 
-DeityRepository repository = ...;
 Deity diana = Deity.builder().withId("diana").withName("Diana").withPower("hunt").builder();
+
 repository.save(diana);
+
 Optional<Deity> idResult = repository.findById("diana");
 Optional<Deity> nameResult = repository.findByName("Diana");
 ----
 
 
 === Beyond JPA
 
-JPA is a good API for object-relationship mapping and it's already a standard in the Java world defined in JSRs. It would be great to use the same API for both SQL and NoSQL, but there are behaviors in NoSQL that SQL does not cover, such as time to live and asynchronous operations. JPA was simply not made to handle those features.
+JPA is a good API for object-relational mapping and it's already a standard in the Java world defined in JSRs. It would be ideal to use the same API for both SQL and NoSQL, but there are behaviors in NoSQL that SQL does not cover, such as time to live and asynchronous operations. JPA was simply not made to handle those features.
 
 
 [source,java]