Currently, when an extended context is retrieved for a linked data search, every possible extended context field is included in the results whether or not content existed in the graph for that field. This is cluttering up the result set.
The request is to only include fields that have values.
The tradeoff is...
WITH BLANK VALUES
The results can be quite long if a lot of context is requested.
The results can be challenging to decipher by a human during debugging.
If the application knows what fields it is expecting AND requests fields by name, they do not need special processing for missing fields.
The application needs special processing for dealing with blank/empty values.
WITHOUT BLANK VALUES
The results only be as long as there are values which means sparsely valued extended context will result in shorter result set.
A human debugging results can easily see that expected context is present.
A human debugging results may not find it as easy to determine that context that should have been present is missing.
If the application knows what fields it is expecting AND requests fields by name, they need special processing for missing fields.
If that application only processes the context it receives without prior knowledge of what to expect, then it doesn't need special processing for dealing with blank/empty values.
It seems like there are more positives to WITHOUT BLANK VALUES.
Currently, when an extended context is retrieved for a linked data search, every possible extended context field is included in the results whether or not content existed in the graph for that field. This is cluttering up the result set.
The request is to only include fields that have values.
The tradeoff is...
WITH BLANK VALUES
WITHOUT BLANK VALUES
It seems like there are more positives to WITHOUT BLANK VALUES.