Disclaimer

The content of this blog is my personal opinion only. Although I am an employee - currently of Nvidia, in the past of other companies such as Iagination Technologies, MIPS, Intellectual Ventures, Intel, AMD, Motorola, and Gould - I reveal this only so that the reader may account for any possible bias I may have towards my employer's products. The statements I make here in no way represent my employer's position, nor am I authorized to speak on behalf of my employer. In fact, this posting may not even represent my personal opinion, since occasionally I play devil's advocate.

See http://docs.google.com/View?id=dcxddbtr_23cg5thdfj for photo credits.

Friday, December 05, 2014

Logic for conditional text

Before I talk more about WYSIWYG for conditional text, an observation:  tagging, labelling text.



For many years FrameMaker only allowed ORing of conditional text tags:  if a piece of text was tagged with both A and B, it would pint if either A or B was true.  There was no way of saying that both A or B had to be true.



Sure, FrameMaker eventually fixed that.  First ANDing. AND NOT. Then parenthesizes. I am not sure if it is arbitrarily complex yet, but it is better than it was. (I wish my company used that version of FrameMaker, or did not use FrameMaker at all.)



In theory all conditions could be expressed by sum of product minterms or product of sum maxterms, with NOT.  Hck, it could all be expressed by NAND and NOR.  But that would be a pain.



Part of the problem is that conditional text tagging is done at different times, by different people - or, worse, simultaneously by people who are not necessarily coordinating.  And that the logical expressions required are fragile - one contributor adding a tag may "EXPLODE" the logical expressions needed to handle his text, when transcluded by somebody else.  Fragile base class all over again!



Say that user1 is producing three versions of a document, tagged V1, V2, V3.  Just those tags are used- no "not-V1".  The logic to determine if text is displayed is not "V1 or V2 or V3" - it is actually "Untagged OR V1 OR V2 OR V3".  If text is tagged both V1 and V2, it displays if either V1 or V2 is being produced, but not V3.



(Much confusion occurs because people forget the implicit "Untagged".  Assuming "Untagged => "display in all versions".)



But user2 has added a different set of tags: let's say TA, TB, TC.  Same logic: "Untagged OR TA OR TB OR TC".



I am deliberately not using binary tags, X and not-X.  I have observed that often tags come in these mutual-??? sets.  Not really mutually exclusive - text may be tagged both V1 and V2.  But the V1 and V2 versions are conceptually separate.  The problem, of course, arises because I often like to create a readable mta-document, a unified version, rather than having to cope with combinatoric explosion.  But that's for later.





Now the user1 and user2 conditions may combine. Combinatoric explosion.



Emphasizing: it is NOT user1.condition OR user2.condition: NOT "Untagged OR V1 OR V2 OR V3" OR "Untagged OR TA OR TB OR TC" => "Untagged OR V1 OR V2 OR V3 OR TA OR TB OR TC".



E.g. we may be generating the combination V1.TB => "(Untagged OR V1) AND (Untagged OR TA)" 





Where people get into trouble is when they try to implement this via a UI (User Interface) which is supposedly simpl, and indicates whether tag is wanted or not via V1wanted=0 or V1wanted=1. Part of the trouble is that, at the very least, you need 3 stats for a wanted predicate: definitely wanted, definitely not wanted, and "I don't care".



As in "I want all text related to V1".



I don't want any text related to V2 (unless it happens to also be tagged related to V1".



And "I don't care if the text tagged V2 is included or not". 



In all cases the text is conceptually passed on to another layer, with the tags intact; and only at the end are all conditions stripped out.



E.g. V[123].T[ABC] => V[12].T[BC] => T[1].T[B].



Worse, the ultimate user may not know of options or tags added by a user earlier in this pipeline.  From the ultimate user's point of view, he may know that he dies not want any TC stuff, but he dos not know if user2 has added a TD alternative.  So the downstream user cannot say TA|TB|TD - he just says "Not TC".  Which is only meaningful in the context of a mutual group T[ABCD], whre "not TC" really means "Untaged OR TA OR TB OR TC" or "Untagged or Any Tag in the T* group except TB".



E.g. a microprocessor family that evolved through 8. 16, 32, and 64 bit versions, like x86 (not to mention 20 and 24 bit stags).



Let's say a user wants just the 8 and 16 bit versions.   If he says "not 32", then he gets 64.  Would that not be strange - having documentation for the 8 16 and 64 bit versions of a CPU, but not the 32?  (Although I can imagine...)



So saying "not 32" normally also implies "not 64".  Or, perhaps "not 32" really means "wordsize < 32" or "wordsize NOT >= 32".



But user1 may introduce a different tag that is not part of this evolutionary sequence - so not-32 should not imply not-virtual-machine.





The problem is that a condition that works at one time may not work going forward, as more tags are added.

No comments: