Thanks for your review! I have updated the RFC document but will need to wait 
for the end of IETF 116 to publish.

Some remarks on your feedback below:

On Wed, Mar 15, 2023, at 5:59 PM, Reese Enghardt via Datatracker wrote:
> Major issues:
> 
> Sections 2.2.1 and 2.2.2
> 
> These sections consider "the [full] name of the entity represented by the
> card". As I'm sure you're aware, names can be complex and contextual, and 
> which
> name to use for a person is not always obvious. [...]

We did not intend to restrict the "name" property to only be certain types of 
names. I now updated the description of this property to be: "The name of the 
entity represented by this Card. This can be any type of name, e.g. it can but 
need not be the legal name of a person."

> 
> Section 2.2.5
> 
> For the grammaticalGender property, it seems that the values should be
> "feminine" (rather than "female"), "masculine" (rather than "male"), and
> "neuter", if the value labels are indeed intended to represent grammatical
> gender (see, for example, the Britannica
> Dictionary: https://www.britannica.com/dictionary/neuter). As an alternative, 
> I
> suggest changing these labels to more closely represent how one would
> respectfully talk about individuals, by changing "neuter" to "gender-neutral"
> while keeping "female" and "male". It is not clear to me why the
> "animate" value exists in addition to the above grammatical genders, as this
> value does not convey information about how to address the entity, but if you
> are sure that there's a use case for this value, I'll defer to your expertise.

Thanks, I renamed "male" and "female" to "masculine" and "feminine".

We used Wikipedia to determine the common contrasts in grammatical genders 
(https://en.wikipedia.org/wiki/List_of_languages_by_type_of_grammatical_genders).
 This includes "animate" and "inanimate" for languages such as Georgian and 
Native American languages.

I realized we did not include "common" but now have added this as well.

> Section 1.5.4
> 
> The descriptions for @type and type sound very similar. Is it possible to 
> state
> more clearly what the difference between the two is? Is it worth
> mentioning/explaining the @ in an earlier notation section?

I added an introductory section to clarify the purpose of the @type property 
and contrast it to the "type" property.

> 
> Nits/editorial comments:
> 
> The word "card" is capitalized in some sections and not others (e.g.,
> capitalized in 2.2.2 but not in 2.2.1) without an obvious difference in
> semantics. Please consider making the capitalization consistent in such cases.

Done

> 
> Section 1.5.2
> 
> "-253+1 <= value <= 2^53-1"
> Can the ^ be removed to make the notation consistent?

Done
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art

Reply via email to