The plist511 xpath operation rule names the wrong parent, so the constraint never applies

[dragosprisaca]

Describe the bug

macos-definitions-schema.xsd line 2405 carries a Schematron rule that can never match. It sits inside the xpath entity of plist511_object, and its pattern id is already macos-def_plist511objxpath, but its context names plist_object:

<sch:rule context="macos-def:plist_object/macos-def:xpath">

plist_object declares app_id, filepath and key. It has no xpath child. plist511_object is the element that declares xpath. The context therefore selects nothing, and the assertion never runs.

The practical effect is that the documented constraint on plist511_object/xpath has never been enforced. Content may set operation="pattern match" (or any other operation) on that entity and validation stays silent, even though the rule intends to allow only equals.

Replication Steps

1. Extract the Schematron from macos-definitions-schema.xsd with tools/ExtractSchFromXSD.xsl and compile it.
2. Validate a document containing a macos-def:plist511_object whose xpath entity carries operation="pattern match".
3. No failed-assert is produced. The same document is accepted whatever operation it uses.

Expected behavior

The rule matches plist511_object/xpath and rejects any operation other than equals.

Content

-<sch:rule context="macos-def:plist_object/macos-def:xpath">
+<sch:rule context="macos-def:plist511_object/macos-def:xpath">

The assertion itself is already correct and needs no change:

<sch:assert test="not(@operation) or @operation='equals'">

OVAL details

• Schema: macos-definitions-schema.xsd
• Object: plist511_object (entity xpath)