Re: New work-queue item: Conditional inclusion

Tim Bray wrote:
 
<snip>

> SGML already comes with a conditionalizing facility, the marked section.
> The effect illustrated above is achievable, with great awkwardness,
> along the lines of
> 
> <![%pe-ref-is-INCLUDE-if-bool-pred-1-is-true;[
>  well-formed XML block 1 ]]>
> <![%pe-ref-is-INCLUDE-if-bool-pred-2-is-true;[
>  well-formed XML block 2 ]]>
> <![%pe-ref-is-INCLUDE-if-none-of-the-boolean-predicates-are-true;[
>  well-formed XML block N ]]>
> 
> This has the important virtue that it is part of SGML and thus there
> exists machinery to handle it.  It also has the virtue that if the 
> user wants to do something like
> 
> <p>Good 
>  <![%IsItMorning;[morning]]>
>  <![%NotMorning;[afternoon]]>
>  !</p>
> 
> they don't need to invent any spurious container elements to handle the
> conditionalization.  But this is also a down-side; the fact that
> this is conditionalized might be of interest to a query or analysis
> facility and thus it should be done in the ordinary way with 
> elements or attributes.  (Subtext: everything without exception
> should be an element or attribute.)
> 
> Other disadvantages of this method are:
> 1. It forces use of parameter entities even in WF docs (blecch!)
> 2. It is not easily parameterized... how would you do a parameter
>    entity that becomes INCLUDE only after a particular time of day,
>    or depending on something in the user profile picked out of the
>    runtime environment?
> 3. It is not easy to see how to achieve the ELSE part of the if-then-else
>    syntax.  And this will be common... one would expect to see a lot of:
>    if (some-special-add-on-capability)
>      text & markup for that capability
>    else
>      vanilla text & markup
> 
> Thus it is worth thinking about doing this at the element level with
> reserved element or attribute syntax?  E.g.

Using marked sections to represent paths through documents is quite 
insufficient.  Essentially, extensive use of marked sections can be
uncomputable (in our life times!).  Hence, for complex document logic, this
is definitely not the way to architect and application.

> 
> <xml-if pred="lots-of-room-to-argue-about-what-goes-here" arg1="" arg2="">
>  <!-- WF xml here -->
> <xml-elsif pred="etc...">
>  <!-- WF xml here -->
> <xml-else>
>  <!-- WF xml here -->
> <xml-endif>
> 
> Or do it in switch/case/COND style:
> <p>Good
>  <xml-cond>
>   <xml-case pred="%time<12:00">
>     morning
>     </xml-case>
>   <xml-case pred="%time>12:00 && %time<17:00">
>     afternoon
>     </xml-case>
>   <xml-default-case>
>     evening
>     </xml-default-case>
>   </xml-cond>
>  !</p>
> 
> Of course, there would be no need to reserve element types - it could all
> be done with attributes on user-selected elements.  Personally I would 
> prefer elements because then the user doesn't have to invent 'em.  What
> did we reserve the namespace for, if not things like this?  Also I 
> like the case/cond/switch approach because you can do a nice simple rigorous
> content model & even enforce a default.
> 
> There is another implicit work item here, but it isn't new.  We assume that
> there will be a way to attach behaviors to elements, and that a boolean
> predicate is one class of behavior.  But this is something that's been
> looming over us for months now - why would you invent elements, anyhow,
> if you couldn't make them do something?
> 
> Another item for the post-July-1 priority queue.  Seems like an
> obvious huge interoperability win to me.
> 

Well, I really don't believe that representing logic in the document is
a good idea.  You should represent the relationships of the data and convey
semantics elsewhere.  Hence, I really do not agree that this is a XML
working group issue.  This is any application semantic.

Lets take the example of the "good morning/afternoon/evening" phrase.

We could describe this as:

<P>Good
<COMPONENTCHOICE NAME="ChooseTimeWord">
<COMPONENTREF LINKEND="Morning">
<COMPONENTREF LINKEND="AfterNoon">
<COMPONENTREF LINKEND="Evening">
</COMPONENTCHOICE>

Where each component is:

<!DOCTYPE TEXTCOMPONENT SYSTEM "literal.dtd">
<TEXTCOMPONENT>
<LITERAL>Morning</LITERAL>
</TEXTCOMPONENT>

<!DOCTYPE TEXTCOMPONENT SYSTEM "literal.dtd">
<TEXTCOMPONENT>
<LITERAL>Afternoon</LITERAL>
</TEXTCOMPONENT>

<!DOCTYPE TEXTCOMPONENT SYSTEM "literal.dtd">
<TEXTCOMPONENT>
<LITERAL>Evening</LITERAL>
</TEXTCOMPONENT>

Now, in some *implementation* language, the logic for "ChooseTimeWord" is
implemented.  

In addition, the above could be transformed using a DSSSL transformation
and the appropriate text substituted.  Hence, both information and 
transformation semantics are encoding in an ISO standard.

==============================================================================
R. Alexander Milowski     http://www.copsol.com/   alex@copsol.com
Copernican Solutions Incorporated                  (612) 379 - 3608

Received on Thursday, 5 June 1997 14:17:04 UTC