OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [dita] Minutes from Ditaval Meeting v2


Some small edits based upon feedback. One meaningless sentence deleted and one phrase (labeled NEW:) added.

====================

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ïve 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 [NEW: and the heaviest kind of underline (double overrides single).]

The defaults for these attributes are application and media specific.




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]