jiebi/TextFlow huggingface dataset:
Original text:
9.2. In addition to the SenML Fragment Identifiers described above, with <del> the XML and EXI SenML formats also the syntax defined in </del>  XPointerFramework can be used.  (This is required by RFC7303 for media types using the "+xml" structured syntax suffix.  SenML allows this for the EXI formats as well for consistency.)

Reviewer comments:
As per Adam's comment, clarify that only the element() scheme of the XPointer Framework is supported (as that is the one that is required by RFC 7303).
LGTM

Revised text:
9.2. In addition to the SenML Fragment Identifiers described above, with  <ins> the XML and EXI SenML formats also the syntax defined in the XPointer element() Scheme XPointerElement of the XPointer Framework </ins> XPointerFramework can be used.  (This is required by RFC7303 for media types using the "+xml" structured syntax suffix.  SenML allows this for the EXI formats as well for consistency.)
Original text:
Some devices have accurate time while others do not so SenML supports absolute and relative times.  Time is represented in floating point <del> as seconds.  Values greater than zero represent an absolute time relative to the Unix epoch (1970-01-01T00:00Z in UTC time) and the time is counted same way as the Portable Operating System Interface (POSIX) "seconds since the epoch" TIME_T.  Values of 0 or less represent a relative time in the past from the current time.  A simple sensor with no absolute wall clock time might take a </del>  measurement every second, batch up 60 of them, and then send the batch to a server.  It would include the relative time each measurement was made compared to the time the batch was sent in each

Reviewer comments:
One possible way to address the problem with positive relative times
NAME Fixed
Looks like two of you are still working details of phrasing but I like where it is going and all looks about right to me.

Revised text:
Some devices have accurate time while others do not so SenML supports absolute and relative times.  Time is represented in floating point  <ins> as seconds.  Values greater than or equal to 2*28 represent an absolute time relative to the Unix epoch.  Values less than 2*28 represent time relative to the current time. A simple sensor with no absolute wall clock time might take a </ins> measurement every second, batch up 60 of them, and then send the batch to a server.  It would include the relative time each measurement was made compared to the time the batch was sent in each
Original text:
All comparisons of text strings are performed byte-by-byte (and therefore necessarily case-sensitive).  4. Each SenML Pack carries a single array that represents a set of

Reviewer comments:
One possible way to address the problem with positive relative times
NAME Fixed
Looks like two of you are still working details of phrasing but I like where it is going and all looks about right to me.

Revised text:
All comparisons of text strings are performed byte-by-byte (and therefore necessarily case-sensitive). <ins> Where arithmetic is used, this specification uses the notation familiar from the programming language C, except that the operator "**" stands for exponentiation. </ins> 4. Each SenML Pack carries a single array that represents a set of
Original text:
If either the Base Time or Time value is missing, the missing field is considered to have a value of zero.  The Base Time and Time values <del> are added together to get the time of measurement.  A time of zero indicates that the sensor does not know the absolute time and the measurement was made roughly "now".  A negative value is used to indicate seconds in the past from roughly "now".  A positive value is used to indicate the number of seconds, excluding leap seconds, since the start of the year 1970 in UTC. </del>  Obviously, "now"-referenced SenML records are only useful within a specific communication context (e.g., based on information on when

Reviewer comments:
One possible way to address the problem with positive relative times
NAME Fixed
Looks like two of you are still working details of phrasing but I like where it is going and all looks about right to me.

Revised text:
If either the Base Time or Time value is missing, the missing field is considered to have a value of zero.  The Base Time and Time values  <ins> are added together to get the time of measurement. Values less than 268,435,456 (2*28) represent time relative to the current time.  That is, a time of zero indicates that the sensor does not know the absolute time and the measurement was made roughly "now".  A negative value indicates seconds in the past from roughly "now".  Positive values up to 2*28 indicate seconds in the future from "now".  Positive values can be used, e.g., for actuation use when the desired change should happen in the future but the sender or the receiver does not have accurate time available. Values greater than or equal to 2*28 represent an absolute time relative to the Unix epoch (1970-01-01T00:00Z in UTC time) and the time is counted same way as the Portable Operating System Interface (POSIX) "seconds since the epoch" . Therefore the smallest absolute time value that can be expressed (2*TIME_T28) is 1978-07-04 21:24:16 UTC. Because time values up to 2*28 are used for presenting time relative to "now" and Time and Base Time are added together, care must be taken to ensure that the sum does not inadvertently reach 2*28 (i.e., absolute time) when relative time was intended to be used. </ins> Obviously, "now"-referenced SenML records are only useful within a specific communication context (e.g., based on information on when
Original text:
A base value is added to the value found in an entry, similar to Base Time.  Version number of media type format.  This attribute is an optional positive integer and defaults to 5 if not present.  [RFC Editor: change the default value to 10 when this specification is

Reviewer comments:
The link was missing from schema. After this is merged, all the example need to be regenerated.
Given we want the l to have a defined integer value in the CBOR table, I think a good approach is define the l attribute as a string here then say what goes in it in the other draft that defines link. This is also good for EXI.

Revised text:
A base value is added to the value found in an entry, similar to Base Time. <ins> A base sum is added to the sum found in an entry, similar to Base Time. </ins> Version number of media type format.  This attribute is an optional positive integer and defaults to 5 if not present.  [RFC Editor: change the default value to 10 when this specification is
Original text:
Base Unit is allowed. Value of the entry.  Optional if a Sum value is present, otherwise <del> required.  Values are represented using three basic data types, Floating point numbers ("v" field for "Value"), Booleans ("vb" for "Boolean Value"), Strings ("vs" for "String Value") and Binary Data ("vd" for "Data Value") .  Exactly one of these four fields MUST appear unless there is Sum field in which case it is allowed to have no Value field or to have "v" field. </del>  Integrated sum of the values over time.  Optional.  This attribute is in the units specified in the Unit value multiplied by seconds.

Reviewer comments:
The link was missing from schema. After this is merged, all the example need to be regenerated.
Given we want the l to have a defined integer value in the CBOR table, I think a good approach is define the l attribute as a string here then say what goes in it in the other draft that defines link. This is also good for EXI.

Revised text:
Base Unit is allowed. Value of the entry.  Optional if a Sum value is present, otherwise  <ins> required.  Values are represented using basic data types.  This specification defines floating point numbers ("v" field for "Value"), booleans ("vb" for "Boolean Value"), strings ("vs" for "String Value") and binary data ("vd" for "Data Value").  Exactly one value field MUST appear unless there is Sum field in which case it is allowed to have no Value field. </ins> Integrated sum of the values over time.  Optional.  This attribute is in the units specified in the Unit value multiplied by seconds.
Original text:
attributes to provide better information about the statistical properties of the measurement. <del> A SenML object is referred to as "expanded" if it does not contain any base values and has no relative times. </del> 4.4.  SenML is designed to carry the minimum dynamic information about measurements, and for efficiency reasons does not carry significant static meta-data about the device, object or sensors.  Instead, it is

Reviewer comments:
The link was missing from schema. After this is merged, all the example need to be regenerated.
Given we want the l to have a defined integer value in the CBOR table, I think a good approach is define the l attribute as a string here then say what goes in it in the other draft that defines link. This is also good for EXI.

Revised text:
attributes to provide better information about the statistical properties of the measurement.  4.4. <ins> Sometimes it is useful to be able to refer to a defined normalized format for SenML records.  This normalized format tends to get used for big data applications and intermediate forms when converting to other formats. A SenML Record is referred to as "resolved" if it does not contain any base values and has no relative times, but the the base values of the SenML Pack (if any) are applied to the Record.  That is, name and base name are concatenated, base time is added to the time of the Record, if Record did not contain Unit the Base Unit is applied to the record, etc.  In addition the records need to be in chronological order. TODO add example 4.5. </ins> SenML is designed to carry the minimum dynamic information about measurements, and for efficiency reasons does not carry significant static meta-data about the device, object or sensors.  Instead, it is
Original text:
A base value is added to the value found in an entry, similar to Base Time.  Version number of media type format.  This attribute is an optional positive integer and defaults to 5 if not present.  [RFC Editor: change the default value to 10 when this specification is

Reviewer comments:
Fixes URL
This makes some of the examples very long. I preferred the presentation where all attributes of a Record are on a single line, when feasible. Especially for the "multiple data points" examples. Anyway, Michael's comment was about indentation, which I agree should be (and is now) fixed.
See email from Michael Koster "Formatting of JSON examples in SenML"

Revised text:
A base value is added to the value found in an entry, similar to Base Time. <ins> A base sum is added to the sum found in an entry, similar to Base Time. </ins> Version number of media type format.  This attribute is an optional positive integer and defaults to 5 if not present.  [RFC Editor: change the default value to 10 when this specification is
Original text:
Base Unit is allowed. Value of the entry.  Optional if a Sum value is present, otherwise <del> required.  Values are represented using three basic data types, Floating point numbers ("v" field for "Value"), Booleans ("vb" for "Boolean Value"), Strings ("vs" for "String Value") and Binary Data ("vd" for "Data Value") .  Exactly one of these four fields MUST appear unless there is Sum field in which case it is allowed to have no Value field or to have "v" field. </del>  Integrated sum of the values over time.  Optional.  This attribute is in the units specified in the Unit value multiplied by seconds.

Reviewer comments:
Fixes URL
This makes some of the examples very long. I preferred the presentation where all attributes of a Record are on a single line, when feasible. Especially for the "multiple data points" examples. Anyway, Michael's comment was about indentation, which I agree should be (and is now) fixed.
See email from Michael Koster "Formatting of JSON examples in SenML"

Revised text:
Base Unit is allowed. Value of the entry.  Optional if a Sum value is present, otherwise  <ins> required.  Values are represented using basic data types.  This specification defines floating point numbers ("v" field for "Value"), booleans ("vb" for "Boolean Value"), strings ("vs" for "String Value") and binary data ("vd" for "Data Value").  Exactly one value field MUST appear unless there is Sum field in which case it is allowed to have no Value field. </ins> Integrated sum of the values over time.  Optional.  This attribute is in the units specified in the Unit value multiplied by seconds.
Original text:
attributes to provide better information about the statistical properties of the measurement. <del> A SenML object is referred to as "expanded" if it does not contain any base values and has no relative times. </del> 4.4.  SenML is designed to carry the minimum dynamic information about measurements, and for efficiency reasons does not carry significant static meta-data about the device, object or sensors.  Instead, it is

Reviewer comments:
Fixes URL
This makes some of the examples very long. I preferred the presentation where all attributes of a Record are on a single line, when feasible. Especially for the "multiple data points" examples. Anyway, Michael's comment was about indentation, which I agree should be (and is now) fixed.
See email from Michael Koster "Formatting of JSON examples in SenML"

Revised text:
attributes to provide better information about the statistical properties of the measurement.  4.4. <ins> Sometimes it is useful to be able to refer to a defined normalized format for SenML records.  This normalized format tends to get used for big data applications and intermediate forms when converting to other formats. A SenML Record is referred to as "resolved" if it does not contain any base values and has no relative times, but the the base values of the SenML Pack (if any) are applied to the Record.  That is, name and base name are concatenated, base time is added to the time of the Record, if Record did not contain Unit the Base Unit is applied to the record, etc.  In addition the records need to be in chronological order.  An example of this is show in resolved-ex. 4.5. </ins> SenML is designed to carry the minimum dynamic information about measurements, and for efficiency reasons does not carry significant static meta-data about the device, object or sensors.  Instead, it is
Original text:
5.1. <del> TODO - Add example with string, data, boolean, and base value </del> 5.1.1. The following shows a temperature reading taken approximately "now"

Reviewer comments:
Fixes URL
This makes some of the examples very long. I preferred the presentation where all attributes of a Record are on a single line, when feasible. Especially for the "multiple data points" examples. Anyway, Michael's comment was about indentation, which I agree should be (and is now) fixed.
See email from Michael Koster "Formatting of JSON examples in SenML"

Revised text:
5.1.  5.1.1. The following shows a temperature reading taken approximately "now"
Original text:
5.1.4.  The following example shows how to query one device that can provide multiple measurements.  The example assumes that a client has fetched information from a device at 2001:db8::2 by performing a GET

Reviewer comments:
Fixes URL
This makes some of the examples very long. I preferred the presentation where all attributes of a Record are on a single line, when feasible. Especially for the "multiple data points" examples. Anyway, Michael's comment was about indentation, which I agree should be (and is now) fixed.
See email from Michael Koster "Formatting of JSON examples in SenML"

Revised text:
5.1.4. <ins> The following shows the example from the previos section show in resolved format. 5.1.5. The following example shows a sensor that returns different data types. 5.1.6. </ins> The following example shows how to query one device that can provide multiple measurements.  The example assumes that a client has fetched information from a device at 2001:db8::2 by performing a GET
Original text:
Characters in the String Value are encoded using a definite length text string (type 3).  Octets in the Data Value are encoded using <del> a definite length byte string (type 2) . </del>  <del> For compactness, the CBOR representation uses integers for the map keys defined in tbl-cbor-labels.  This table is conclusive, i.e., there is no intention to define any additional integer map keys; any extensions will use string map keys.  This allows translators converting between CBOR and JSON representations to convert also all future labels without needing to update implementations. </del>  For streaming SensML in CBOR representation, the array containing <del> the records SHOULD be an CBOR indefinite length array while for non streaming SenML, a definite length array MUST be used. </del>  The following example shows a dump of the CBOR example for the same sensor measurement as in co-ex.

Reviewer comments:
Set of small editorial tweaks and aligned fragment text with new way of positioning base values
LGTM ( other than we need to decide if we use field or attribute but we can do that as separate PR)

Revised text:
Characters in the String Value are encoded using a definite length text string (type 3).  Octets in the Data Value are encoded using  <ins> a definite length byte string (type 2). </ins>  <ins> For compactness, the CBOR representation uses integers for the labels, as defined in tbl-cbor-labels.  This table is conclusive, i.e., there is no intention to define any additional integer map keys; any extensions will use string map keys.  This allows translators converting between CBOR and JSON representations to convert also all future labels without needing to update implementations. </ins> For streaming SensML in CBOR representation, the array containing  <ins> the records SHOULD be a CBOR indefinite length array while for non-streaming SenML, a definite length array MUST be used. </ins> The following example shows a dump of the CBOR example for the same sensor measurement as in co-ex.
Original text:
The compressed form, using the byte alignment option of EXI, for the above XML is the following: <del> A small temperature sensor devices that only generates this one EXI </del>  file does not really need an full EXI implementation.  It can simply hard code the output replacing the 1-wire device ID starting at byte 0x20 and going to byte 0x2F with it's device ID, and replacing the

Reviewer comments:
Set of small editorial tweaks and aligned fragment text with new way of positioning base values
LGTM ( other than we need to decide if we use field or attribute but we can do that as separate PR)

Revised text:
The compressed form, using the byte alignment option of EXI, for the above XML is the following:  <ins> A small temperature sensor device that only generates this one EXI </ins> file does not really need an full EXI implementation.  It can simply hard code the output replacing the 1-wire device ID starting at byte 0x20 and going to byte 0x2F with it's device ID, and replacing the
Original text:
first record is at position 1.  A range of records can be selected by giving the first and the last record number separated by a '-' character.  Instead of the second number, the '*' character can be <del> used to indicate the last Senml Record in the Pack.  A set of records </del>  can also be selected using a comma separated list of record positions or ranges. (We use the term "selecting a record" for identifying it as part of the fragment, not in the sense of isolating it from the Pack -- the record still needs to be interpreted as part of the Pack, e.g., using <del> the base values defined in record 1.) </del>  9.1.

Reviewer comments:
Set of small editorial tweaks and aligned fragment text with new way of positioning base values
LGTM ( other than we need to decide if we use field or attribute but we can do that as separate PR)

Revised text:
first record is at position 1.  A range of records can be selected by giving the first and the last record number separated by a '-' character.  Instead of the second number, the '*' character can be  <ins> used to indicate the last SenML Record in the Pack.  A set of records </ins> can also be selected using a comma separated list of record positions or ranges. (We use the term "selecting a record" for identifying it as part of the fragment, not in the sense of isolating it from the Pack -- the record still needs to be interpreted as part of the Pack, e.g., using  <ins> the base values defined in earlier records) </ins> 9.1.
Original text:
Extensions that add a label that is intended for use with EXI need to create a new XSD Schema that includes all the labels in the IANA <del> registry then allocate a new EXI schemaId value.  Moving to the next letter in the alphabet is the suggested way to create the new value for the EXI schemaId.  Any labels with previously blank ID values SHOULD be updated in the IANA table to have their ID set to this new schemaId value. </del>  Extensions that are mandatory to understand to correctly process the Pack MUST have a label name that ends with the '_' character.

Reviewer comments:
Set of small editorial tweaks and aligned fragment text with new way of positioning base values
LGTM ( other than we need to decide if we use field or attribute but we can do that as separate PR)

Revised text:
Extensions that add a label that is intended for use with EXI need to create a new XSD Schema that includes all the labels in the IANA  <ins> registry and then allocate a new EXI schemaId value.  Moving to the next letter in the alphabet is the suggested way to create the new value for the EXI schemaId.  Any labels with previously blank ID values SHOULD be updated in the IANA table to have their ID set to this new schemaId value. </ins> Extensions that are mandatory to understand to correctly process the Pack MUST have a label name that ends with the '_' character.