RE: [dita] otherprops syntax - should we specify?

For the spec, I'd suggest slightly rephrasing the discussion of exclusion and flagging in terms of matching.

match-expression has the form set-of-attributes(list-of-spacedelimited-values(value-to-match))

Let attribute-values-on-element be a match-expression on an element

Let control-values be a list of match-expressions from exclude (respectively, flag) <prop> statements

Let control-value-summary be a match-expression built by accumulating, in each attribute, all the values from control-values for exclude <prop> statements (respectively, for flag <prop> statements)

Exclude(element-instance, control-values, attribute-values-on-element) if for any attribute, all the values in attribute-values-on-element are also included for that attribute in control-value-summary. Otherwise, include the element.

Flag(element-instance, control-values, attribute-values-on-element, action) if for all attributes (?), some value in attribute-values-on-element is also included in control-value-summary. The result of a match on flag(element-instance, ...) is that the action is performed on the element.

If Exclude(element-instance, ...) and Flag(element-instance, ...) both match, then the element-instance is excluded.

== B ==

I wonder whether the entire conditional processing facility should be specified as a current practice. In case revisions are made for R2.0, consideration would be given to conversion. If the fundamental logic is revisited, it should be possible to improve while supporting the existing capabilities, but it would be awkward later if automatic convertability were promised and not achieved.

== C ==

The conditional processing facility has both brilliant and simple features, but there are several assumptions built in to the existing mechanism that might be subject to revision or rework in a future edition of the spec. Assumptions include:

1. To specify the category in which a set of conditional values operates, an attribute name should be defined.

2. To specify an individual value for a category, a single token suffices. Logical combinations and structural relationships cannot be stated.

Logical combination of individual values within a category is determined by the function being performed.

Interpretation of the significance of the presence of a value is determined by the function being performed. For example, an author cannot specify "include only if the product matches"; this would be done by the processing. (In practice, the processing data could consist of a list of all products and merely comment out those that are not to be excluded, which might be a practical way to manage it, but if a facility for include were offered, the opposite would also work. The include-based processing would be more robust in case an author wrote something product-specific for a new product and the processing was not updated. Also, if the processing data applies to a large scope of authored information, the processing data would be smaller for include-based processing.)

3. No "all" and "none" values are defined.

4. The exclude and flag functions are explicit. No include function is defined.

5. The effect of the action for the flag function is not specified. The example illustrates how text might appear in the output but not how a graphic or other more dramatic action might be specified.

6. The system of processing properties is processed in a cumulative, not a serial manner. Therefore any overrides must be provided for in the processing logic. The data that specifies the processing properties must be chosen with the processing logic in mind; there is no modular, data-driven system of overrides that works across logical contexts.

Looking at this list of assumptions, it is clear that relaxing all of them completely might lead to great complexity. It would not be practical to define a maximally-expressive facility for conditional logic unless there are also definite limits on what combinations of features, or what complexity of expressions, can be supported by an efficient and implementable processing system.

dita message