%ZHSLIB.PackageManager.Developer.Annotation.Tag.AnchorTag

flag to indicate whether a COS entity that allows this tag should always have XML for that tag, even if it's omitted from the annotations. Such extra XML representation will not use a default instance of the tag, but one constructed by calling ConstructMissingMandatoryTag(). This allows us to have different behavior between a) omitted things and b) things included without modifiers, e.g. "Extensible" by itself should have "universal" availability, while omission means "forbidden".

whether we should add this tag object to the entity's Tags. We set this to 0 in tag classes that affect the tag processing behavior but which should not appear in the API XML. This is necessary because there is no way to exclude it from the XML; setting the XMLENABLED parameter to 0 causes errors because every class referenced by an xml-enabled class (when generating XML) must be enabled also, and the tags are all mixed together in the ..Tags relationship of the COS entity object. We could also try to store them differently in the COS entity but that would make all the other tag handling more complex.

Contains keywords for modifiers that are universally applicable to all tags. Not intended to be overridden.

note that we tried using a COSEXPRESSION to generate the XMLNAME from the class name, using the obvious simple rule: $replace($piece($classname(),".",6,*),".","_") . While this works when evaluated with $parameter(), the XML writer can't use it because it relies on run-time expression execution and the XML output is done via generated code. Using a curly-braces "evaluate at compile time" expression also does not work, even if we use %classname instead of $classname(); maybe the XML.Adaptor code generation doesn't support the {} syntax regardless. See prodlog 148118 So we have to provide the obvious XMLNAME value explicitly in all the tag subclasses.

By default, all tags are inherited. Tags on a class are inherited by its subclasses, and tags on a class's members are inherited by the members in subclasses. However, we allow a modifier to block this, like so: Using this modifier only affects the behavior of the annotation tags. It does not affect how the COS members are inherited, that's the domain of COS. The modifier can apply to any tag.

reference to the class proxy object that ParentCosEntity is part of. For class proxy objects, this will return $this.

note that this relationship should have an "OnDelete = cascade" keyword, but this does not work correctly. Attempting to accomplish the same effect with an "on delete" trigger in the CosEntity table also does not work. see prodlog 148120 Therefore, anytime we delete CosEntity objects we must explicitly delete its related AnchorTag objects first.

tags can have properties that either appear as "extra content" in the same tag line (e.g. @API.Deprecated 2.12.4), or as modifiers on a separate line (e.g. @Modifier Availability Universal). Many of these also need to be able to be overridden in APIANNOTATIONS XData blocks, which we parse into arrays for easier processing. This method is for applying those properties/attributes coming from the XData blocks.
This leaves us supporting exactly two: the Availability modifier and the Version properties for Deprecated and Since. But the intent is to support more options later if needed.
The array passed in should be of the form pPropertyValues("Property") = "Value"