updates

Signed-off-by: Shaobo He <shaobohe@amazon.com>

text/0072-oem.md

@@ -23,18 +23,20 @@ The following Rust code defines how type `Team` and type `Member` map to entity
 struct Team {
   #[cedar(eid)]
   id: String,
-  members: HashSet<Member>
+  members: HashSet<Member>,
+  #[cedar(skip)]
+  nickname: String,
 }
 
 #[derive(Debug, Clone, Cedar)]
-#[cedar(transparent)]
+#[cedar(type=record)]
 struct Member {
   name: String,
   #[cedar(rename="region")]
   location: Option<String>,
 }
 ```
-An object `Team { id: "A", members: { Member { name: "alice", location: Some("West")}, Member { name: "bob", location: None}}}` is converted to the following entities in JSON,
+An object `Team { id: "A", nickname: "AAA", members: { Member { name: "alice", location: Some("West")}, Member { name: "bob", location: None}}}` is converted to the following entities in JSON,
 
 ```JSON
 [
@@ -45,7 +47,7 @@ An object `Team { id: "A", members: { Member { name: "alice", location: Some("We
             "members": [
                 {
                     "name": "alice",
-                    "location" "West"
+                    "region": "West"
                 },
                 {
                     "name": "bob"
@@ -67,9 +69,9 @@ Moreover, OEM can potentially facilitate the adoption of Cedar on applications u
 
 Given limited knowledge about Rust macros the proposer has, the design details are subject to significant changes.
 
-The macros over a Rust type eventually expand to implementations of `Into<Entities>`. In the meantime, they also give rise to implementations of `Into<Value>` for this type. By default, the implementation of `Into<Value` for a type produces an entity `uid` unless the type is annotated with the `#[cedar(transparent)]` clause, where it produces a record.
+The macros over a Rust type eventually expand to implementations of `Into<Entities>`. In the meantime, they also give rise to implementations of `Into<Value>` for this type. By default, the implementation of `Into<Value>` for a type produces an entity `uid` unless the type is annotated with the `#[cedar(type=record)]` clause, where it produces a record.
 
-The implementation of `Into<Entities>` for any type annotated with the `#[cedar(transparent)]` clause produces an empty entity slice. Those for types without such annotations construct an entity by iterating its fields. If a field type corresponds to an entity type, the entity slice derived from the field is merged into the final resulting entity slice. That is the reason why a Rust object converts to an entity slice instead of a single entity.
+The implementation of `Into<Entities>` for any type not annotated with the `#[cedar(type=entity)]` clause produces an empty entity slice. Those for types without such annotations construct an entity by iterating its fields. If a field type corresponds to an entity type, the entity slice derived from the field is merged into the final resulting entity slice. That is the reason why a Rust object converts to an entity slice instead of a single entity.
 
 ### Value mapping
 
@@ -80,6 +82,8 @@ We require all types of struct fields to implement `Into<Option<Value>>`. The `O
 
 We use clause `#[cedar(rename=...)]` to describe entity type/attribute name mappings, where the argument is the string representation of an entity type or attribute name. Entity type/attribute name is the Rust type/field name without such clause.
 
+We allow the conversion to ignore certain fields by annotating them with `#[cedar(skip)]`. Note that this makes OEM unidirectional. That is, we can only convert objects into entities, not the opposite.
+
 ### Eid mapping
 
 We use clause `#[cedar(eid)]` to denote the field corresponding to the `Eid`. We require the field type to implement `ToString`.