Friction: {x:Null} Verbosity

The generators emit {x:Null} for many properties that may not require explicit null serialisation. This verbosity was inherited from Studio exports without distinguishing between required and defensive nulls.

How It Entered the Codebase

Studio's XAML serialiser emits every property it knows about, including optional ones not set by the user. When the generator f-strings were derived from the stripped Studio exports, all {x:Null} entries were carried forward verbatim — there was no analysis of which ones Studio actually requires at load time.

The NetHttpRequest Case

The most visible example: gen_net_http_request in http_json.py explicitly lists ~17 properties that must be set to {x:Null}:

null_props = [
    "BasicAuthPassword", "BasicAuthSecurePassword", "BasicAuthUsername",
    "BinaryPayload", "ClientCertPassword", "ClientCertPath",
    "ClientCertSecurePassword", "Cookies", "CustomNegotiatedAuthCredentials",
    "FilePath", "FormData", "LocalFiles", "OutputFileName",
    "OutputFileTargetFolder", "PathResource", "ProxyConfiguration", "ResourceFiles",
]
null_attrs = " ".join(f'{p}="{{x:Null}}"' for p in null_props)

The comment states these are required to avoid Studio warnings. But this claim was derived from the Studio export — it was not verified by testing removal of each entry individually.

The Two Categories

{x:Null} entries fall into two categories that the codebase does not distinguish:

Genuinely load-bearing — omitting causes Studio to crash, show a validation error, or silently misbehave. These must remain.

Defensive serialisation — Studio emits these when it knows about a property but the user left it unset. They are safe to omit; XAML will deserialise correctly using the activity's default value. Studio will re-add them on the next save.

Why This Matters

The current test suite cannot distinguish between the two categories. The snapshot tests lock the output (including all nulls) and the lint tests check for specific malformed patterns — neither tests minimal XAML.

The consequence for a version-aware registry refactoring: a registry built from NuGet package metadata would not include {x:Null} entries at all (they are not properties — they are the absence of a value). A dynamic generator would need a separate mechanism to know which nulls to emit, or would need to rely on testing to determine which are load-bearing.

Testing Approach to Distinguish Them

The only reliable method to classify {x:Null} entries is:

1. Remove the entry from a generated XAML file
2. Run uipath pack against the project
3. If pack succeeds: the null was defensive
4. If pack fails with a specific error: the null is load-bearing

This is a one-time audit per activity per package version, suitable for inclusion in a validation pipeline. See External Registry and Validation Pipeline.