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] Thoughts on Issue #20


 


From: Michael Priestley [mailto:mpriestl@ca.ibm.com]
Sent: Tuesday, April 04, 2006 8:09 AM
To: Paul Prescod
Cc: dita@lists.oasis-open.org
Subject: Re: [dita] Thoughts on Issue #20


re 1:  there is a req to strip values from output - you don't want internal rev numbers or values that reference unreleased products being included in output, for example. So there do have to be two actions - include content while stripping values, and include content while preserving values. Don't much care what we call them. 
 
Okay, fine.
 re 2: dunno. 
I'll regard it with suspicion until someone speaks up.
 re 3: since this part was your idea, I'm happy to take suggestions :-) In the previous/existing behavior, only the rev attribute could be flagged with color, so this situation never came up. 
 Okay, I'll ask Su-Laine to propose something. She's thought it about it quite a bit in the XMetaL visualization context. (we already implement flagging with colours)
re 4: not sure I understand your grounds for objection fully, but in any case the proposal does describe how to change the default behavior for a particular ditaval file, but I'm reluctant to change the default for every ditaval file because, regardless of the merits of your argument, it would be backwards incompatible (ie every document out there created based on existing default behavior would break with your change). Hence my desire to make the change an opt-in rather than global. 
First: Can we have a more explicit syntax for this? E.g. a <default> element with an occurrence pattern of singleton?
 
Second: I'm not convinced that setting the default ends up with the behaviour that I believe is intuitive and consistent. It isn't that I want the default to be "exclude". As in the document, I want the following behaviour:
 
 1. if an attribute is not mentioned at all in the ditaval, then ignore it (include elements that have it set, no matter what the value)
 
 2. if any attribute value is mentioned positively in the ditaval and in the document, then include the element
 
 3. Otherwise: the attribute has values with a positive mention but none of them match the element. Exclude it.
 
If I set the default to be "exclude" then the first rule will be violated. This becomes a problem when new conditionality attributes are added and old ditaval files are used. Your instinct of "include by default" is the best in that case.
 
 Paul Prescod
 


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