On Thu, Mar 25, 2010 at 2:50 PM, Hussein Shafie <hussein at xmlmind.com> wrote:
> That's right. We don't understand the description of the "props" attribute:
> ---
> props = Root attribute from which new metadata attributes can be
> specialized.
> ---
> Therefore this attribute is currently completely ignored by ditac.
>
> To be frank, we don't understand anything related to attribute
> specialization (or is it generalization?). We only understand element
> specialization.
We have several of our own conditionals to deal with both internal and
external customers and variations of the documents we need to produce.
Specializing conditionals means the markup is more readable. More
importantly, if that is possible, it means that the tools we use can
help us, so that the editor knows what values go with which
attributes. This avoids typos in customer names. product variations,
etc, etc, etc.
> May be it's a bug but we currently do not understand how this is really
> supposed to work. Therefore we are not going to fix it.
As you pointed out below, you must understand how it works because it
works just fine when our conditionals are used inside of individual
topic .xml files. I'm confused.
> If you replace attribute "weebles" by attribute "otherprops" everywhere
>
> in your sample files, it will work exactly as expected. See attached files.
We are not going to do that:
* For one, it breaks the help that XML/DITA editors can give us.
* For anther we have several orthogonal new conditions. Weebles was
just an example/simplification.
DITA is defined that if any of the contents of a conditional survive
the filtering, the element will survive. That utterly breaks when you
have to jam more than one kind of conditional into a single "other
props" solution. For example, I might have a paragraph that applies
only to customer X and only to situation Y. If I put both X and Y into
otherprops, the meaning becomes: include this paragraph when -either-
X -or- Y are 'included'.
Having separate conditionals gets me the correct semantics of X -and-
Y. HUGE difference. :)
> Now it's true that ditac allows to specify any attribute (including
> "weebles") in the .ditaval file to perform conditional processing. This
> explains why you have found it to partially work.
And explains why I would expect the exact same markup to have the
exact same effect in the map file!? Attribute "foo" has the values to
include/exclude in the ditaval, so it should be processed the same in
the map as in the topic xml files. :) I understand from your
explanation above (elided) that it will not.
> However ditac will not attempt to move attributes other the standard
> conditional processing ones from the topicref to the corresponding
> topic. This explains why it works fine with "otherprops" and not really
> with "weebles".
Is that a crucial decision? Can it least throw an error when it finds
a topicref with attributes which it isn't going to process properly?
Last thing we want is an author to think they've properly
conditionalized something as "secret" only to have it pop out in a
document for a customer!
I hope I have explained above why jamming all of our conditionals into
one otherprops is not correct and is not something we can do.
Based on your (elided) description, I attempted to put my conditionals
on the top level element in my .XML (a <concept> in this case), but
that generated an error:
ditac: ERROR: fatal error reported by the XSLT engine: A sequence of
more than one item is not allow ed as the first operand of 'ge' (2, 6)
; SystemID: file:/C:/ditac-1_2_0/xsl/fo/pagination.xsl; Line#: 627;
Column#: -1
ditac: ERROR: cannot transform "<my-file-name-here>.ditac" to
"<my-file-name-here>.fo" using file: /C:/ditac-1_2_0/xsl/fo/fo.xsl: A
sequence of more than one item is not allowed as the first operand
of 'ge' (2, 6)
So, how do I work around this to get X -and- Y processing for entire topics?
Thanks,
-Doug
