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



CSS should be able to as long as the values are blank-delimited. Eclipse has its own syntax and attribute, eg <span filter="ws=win32">stuff</span>.

How about we just say passthrough should preserve the values in whatever syntax is supported by the runtime filtering or flaggering engine, and if the engine is unknown to default to the generalized syntax?

Michael Priestley
IBM DITA Architect and Classification Schema PDT Lead
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25



"Paul Prescod" <paul.prescod@xmetal.com>

05/16/2006 11:46 PM

To
Michael Priestley/Toronto/IBM@IBMCA
cc
<dita@lists.oasis-open.org>, "Esrig, Bruce \(Bruce\)" <esrig@lucent.com>, "Robert D Anderson" <robander@us.ibm.com>, "Su-Laine Yeo" <su-laine.yeo@xmetal.com>
Subject
Re: [dita] Minutes from Ditaval Meeting





Can CSS or Eclipse read the parenthesized syntax described in the proposal?
 



From: Michael Priestley [mailto:mpriestl@ca.ibm.com]
Sent:
Tuesday, May 16, 2006 7:56 AM
To:
Paul Prescod
Cc:
dita@lists.oasis-open.org; Esrig, Bruce (Bruce); Robert D Anderson; Su-Laine Yeo
Subject:
[SPAM] Re: [dita] Minutes from Ditaval Meeting
Importance:
Low


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
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25

"Paul Prescod" <paul.prescod@xmetal.com>

05/16/2006 08:35 AM


To
Michael Priestley/Toronto/IBM@IBMCA, "Su-Laine Yeo" <su-laine.yeo@xmetal.com>, "Robert D Anderson" <robander@us.ibm.com>, "Esrig, Bruce \(Bruce\)" <esrig@lucent.com>
cc
<dita@lists.oasis-open.org>
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´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

Element called styleconflict, a foreground color, background color and a style.

The defaults for these attributes are application and media specific.




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