--> I now understand what you want to achieve and why you prefer to do it this way.
There are probably more issues with ditac than you imagine. In order to fix *all* the problems, we need an example (topics, map, *several* ditavals), as simple as possible, showing *all* the features you need. For example, you'll have to show us how you specify: include this element but only when customer="X" and situation="Y". Ditac currently has a low priority on our development schedule. Therefore I'm sorry to say that it may take weeks, if not months, before we release a new version of ditac. --> The bug below is almost certainly unrelated to the above issues: --- 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 --- In order to fix it, we need to be able to reproduce it. Thank you for your patience and thank you for helping us to improve XMLmind DITA Converter (ditac). Douglas W Philips wrote: > 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 > > -- > XMLmind DITA Converter Support List > ditac-support at xmlmind.com > http://www.xmlmind.com/mailman/listinfo/ditac-support > >
