Query param meanings: "XML element" => "element"

[RalphTro]

Hi @CraigRe , A minor thing: there are various definitions for e.g. EQ_INNER_SENSORELEMENT_fieldname, for which the meaning explanation was expanded with "matches inner extension elements (i.e., any XML element nested at any level within a top-level extension element)" Suggestion: instead of 'XML element', go for 'element' so that it also applies for JSON/JSON-LD.

[mgh128]

JSON/JSON-LD don't have "elements" either. XML and JSON/JSON-LD have data fields or attributes/properties.

The problem also arises in the description for EQ_fieldname and probably throughout section 8.2.7.1 where we'll need to carefully check each occurrence of 'element'.

For example, the description for EQ_fieldname includes:

“Top level” means that the matching extension element must be an immediate child of the containing EPCIS event, not an element nested within a top-level event extension element. See EQ_INNER_fieldname for querying inner extension elements.

This could be rewritten as:

“Top level” means that the matching extension data field must be nested as an immediate child attribute of the containing EPCIS event, not a data field nested within a top-level event extension element or class. See EQ_INNER_fieldname for querying data fields nested within extension elements / classes.

[CraigRe]

Will harmonise within EPCIS § 8.2.7.1 to reflect "property" (in place of "element"), where appropriate. Sometimes these may be considered as data fields or inline xml attributes. Care must be taken to distinguish between classes and properties, using Mark's updated UML diagram as an authoritative reference.

[mgh128]

Still overlooked but noted in a public review comment as needing attention so that the terminology is syntax neutral