New work-queue item: Conditional inclusion

Netscape sees a strong need for a conditional-inclusion facility in XML.  
The historical absence of such a facility in HTML has led to problematic
features such as <NOFRAMES>.  This is something that will commonly be
needed across virtually every class of application and, for interoperability,
is a good candidate for inclusion either in XML-LANG directly or in
one of the basic series of specs.

Ideally, the semantic (syntax totally aside) would be something along
the lines of

if (boolean-predicate-1)
 well-formed XML block 1
elsif (boolean-predicate-2)
 well-formed XML block 2
else
 well-formed XML block N
endif

Note that the requirement that the body of any conditional construct be
well-formed XML removes any uncertainty about being able to distinguish
the conditionalizing syntax from the rest of it.  

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.

<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.

Received on Thursday, 5 June 1997 11:53:41 UTC