Re:
I personally felt that unless there is some engine
that can interpret these pass-throughs, there is no use putting the feature
in the spec. After all, output engines tend to evolve independently of
the DITA specification. If Michael knows that the Eclipse team is thinking
about runtime filtering then fine, leave it in. But if they still need
to be convinced then I'd rather the convincing happen before the specification
does. After all, if an output or display engine wanted to add that feature
it could do so independent of DITA.
Regardless of Eclipse (which already
supports runtime filtering), CSS does. If the values are passed through
to the HTML, different CSSs can be applied to flag different things.
Michael Priestley
IBM DITA Architect and Classification Schema PDT Lead
http://dita.xml.org/blog/25
"Paul Prescod"
<>
05/16/2006 08:35 AM
To
Michael Priestley/Toronto/IBM@IBMCA,
"Su-Laine Yeo" <>, "Robert
D Anderson" <>, "Esrig, Bruce \(Bruce\)"
<>
cc
<>
Subject
[dita] Minutes from Ditaval
Meeting
I realized that I hadn't seen any email on the ditaval
proposals. Then I realized that that was because the email was sitting
in my outbox. Sorry for the delay! Also: I'm in transit and will not make
the phone call today.
====================
Attendees
=========
Robert Anderson, IBM
Bruce Esrig, Lucent
Paul Prescod, XMetaL
Su-Laine Yeo, XMetaL
Discussion
==========
The specification should state that there can be at most one occurrence
of a "prop" element with no attribute specified, at most one
for each attribute with no value specified, and at most one with each attribute
value specification.
There is a section of the specification that refers to the scoping syntax
even though it has been removed. Search the spec for the word "scoped".
The description of the passthrough attribute was not obvious to all readers.
In particular, it wasn't clear that passthrough implies inclusion. This
is also true of the flag attribute.
It would be helpful to have a motivating use case for passthrough. Also,
it would be helpful to know what it means in contexts other than HTML output.
I personally felt that unless there is some engine that can interpret these
pass-throughs, there is no use putting the feature in the spec. After all,
output engines tend to evolve independently of the DITA specification.
If Michael knows that the Eclipse team is thinking about runtime filtering
then fine, leave it in. But if they still need to be convinced then I'd
rather the convincing happen before the specification does. After all,
if an output or display engine wanted to add that feature it could do so
independent of DITA.
There are places where the specification refers to the action attribute
as "action" rather than "@action". This is inconsistent
with other attributes.
There was some enthusiasm for the idea that implementations issue a warning
or informational message in the case that an attribute or attribute value
occurs in the content but not in the DITAVAL. It seemed somewhat na鴳e
to presume that the right behaviour is just "include". If someone
adds a parallel step to your task that only applies to some context that
is not relevant to you, then you want it to GO AWAY by default, not be
output by default.
We found it confusing that the alternative text attributes occurred on
different elements than the image references themselves. We propose instead
elements like start-image and end-image.
There was some enthusiasm for text-based prefixes and postfixes as an alternative
to images. We proposed "start-text" and "end-text"
as element names. One proposal was to collapse the start-text-alt element
and the start-text element by saying that the text be used as alternative
text if there was an image supplied or as prefix text if there was not.
Others found this confusing.
We should specify a way for images to be conditionally flagged. For example,
something along the lines of: "if a background color is expressed
for an image, it should be represented as a thick border. If a foreground
color is expressed, it should be represented as a thin border."
We proposed to take out the list of colour names in the specification.
They could be included by reference as suggested by Paul Grosso.
On the other hand, the link to the XSLT specification implies that DITAVAL
processors should support the syntaxes defined here:
http://www.w3.org/TR/xsl/slice5.html#expr-color-functions
We should be explicit about what syntaxes we support. I personally would
like to know whether XSL will synchronize with SVG and CSS as defined here:
http://www.w3.org/TR/css3-color/#svg-color
Somehow we need a clear definition of what syntax the attribute supports.
It doesn't matter much what the syntax is.
In the descriptions of @startimg and @endimg, we felt that everything before
the comma is redundant: "If flag has been set, the image to use for
flagging the beginning of flagged content." On the other hand, it
would be good to say whether it is an error to specify the @startimg with
@action=include, @action=exclude or @action=passthrough.
Printchar is a big open issue. There are three models: HTML, FO and IBM-existing.
Nobody knows whether HTML supports changebars. My proposal: keep princhar
for internal IBM use, but deprecate it. Add a coloured changebar feature
that would degrade gracefully to a background color in formats that do
not support change bars.
If we add the start-text feature then the ">>" and "<<"
characters described in the spec could be DEFAULTS for revprop behaviour.
Proposal for Conflicts
======================
We proposed to handle style conflicts with a singleton element called "styleconflict"
that would allow ditaval authors to say what happens in the case of a style
conflict. It would have foreground-conflict-color and a background-conflict-color
attributes.
If two rules style the same element with a different background colour,
then fall back to the styleconflict/@background-conflict-color.
If two rules style the same element with a different foreground colour,
then fall back to the styleconflict/@foreground-conflict-color.
If two rules style the same element with two different types of underline,
then use the styleconflict/@foreground-conflict-color
Element called styleconflict, a foreground color, background color and
a style.
The defaults for these attributes are application and media specific.
