== A
==
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.
Bruce
Esrig
-----Original Message-----
From: Michael Priestley
[mailto:]
Sent: Thursday, January 06, 2005 2:21
AM
To: DITA TC list
Subject: [dita] otherprops syntax -
should we specify?
Just
wanted to start the discussion on the list. For background, take a look at the
conditional processing topic in the current draft of the spec.
In the conditional processing section, it
says:
"Each attribute takes zero or more
space-delimited string values."
Now, this is fine for semantically
grouped values like those in the product or audience attributes, but is
inadequate for otherprops, which might contain multiple semantic groupings.
For example, otherprops might take parenthetical groupings of values as well
as directly contained values.
Chris Wong pointed out that because we haven't specified the syntax of
otherprops in the past we could invalidate some existing designs by specifying
it now.
We might be able to
address this concern either by basing our design on the existing one if it
passes muster, or if there are multiple designs in use we could soften the
wording from a requirement to a recommendation in the case of otherprops.
Otherwise I think we leave a hole
in the specification that could result in multiple incompatible
implementations of conditional processing code, and content that becomes tied
to one implementation or the other.
Michael
Priestley
