Re: New work-queue item: Conditional inclusion

Tim Bray <tbray@textuality.com> writes:
> 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.

A conditional markup feature has been a WWW 'requirement' for a long time.
We talked about this in the latter days of the HTML working group under
the guise of "HTML feature set negotiation". This was discussed at the
LA IETF meeting last year, and it basically followed the notion of using
marked sections with keywords set by negotiated parameters in the UA.

> 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

The big problem with MS was lack of an 'elseif' structure, where there
is no enforcement of exclusivity of any MS within the same group of marked
sections (which henceforth I'll for convenience sake call a 'family').

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

A requirement similar to any content inclusion.

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

Well, it's assuredly awkward if you insist on such laborious keyword names.
Let's try that again with something more reasonable:

  <![ %pre1; [
   well-formed XML block 1 ]]>
  <![ %pred2; [
   well-formed XML block 2 ]]>
  <![ %predn; [
   well-formed XML block N ]]>

But this doesn't solve the earlier question, as to how to provide an 'elseif'
mechanism that isn't reliant upon the correct use of MS keywords to provide
exclusivity within the family. An actual structure would be akin to the
following, which is certainly more awkward, and unfortunately amplified by
the default 'INCLUDE' behavior of a MS set by an undefined/unspecified keyword:

   <![%pre1;[
   well-formed XML block 1 
   <!ENTITY % pred2 "IGNORE">
   <!ENTITY % pred3 "IGNORE">
   ...
   <!ENTITY % predn "IGNORE">
   ]]>
  <![%pred2;[
   well-formed XML block 2 
   <!ENTITY % pred3 "IGNORE">
   ...
   <!ENTITY % predn "IGNORE">
  ]]>
  <![%predn;[
   well-formed XML block N ]]>

ad nauseum...

We simply can't get there using marked section syntax --we'd also put quite
an onerous requirement on the author, a difficult enforcement requirement
on the UA, and certainly not usable within an instance unless we're 
nuts enough to allow entity declarations within the instance. And moving
the entity declarations to somewhere distant from the marked sections makes
this usage even less portable and readable.

> [use of marked sections] 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
[further description...]
> 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

Agreed, as discussed above. But I think it's worth keeping MS syntax
rather than discard it for an entirely new syntax as you propose
(which would make conversion more difficult I believe). Perhaps a
modification to marked sections that works only within XML but is
nominally SGML compatible?

Back in the days of HTML feature set negotiation I thought of an
alternative that closely follows SGML MS syntax, but adds the concept
of MS 'families'. Under certain circumstances this would change a MS 
behaviour from a 'checkbox' to a 'radio button', by using a 'class' or
'family' attribute.

  <![ %pre1; (family="1") [
    well-formed XML block 1  
  ]]>
  <![ %pred2; (family="1") [
    well-formed XML block 2 
  ]]>
  <![ %predn; (family="1") [
    well-formed XML block N
  ]]>

where the first marked section encountered of (family="1") automatically
excludes further marked sections of the same family designation. The 
actual syntax probably isn't that important at this point, but I would much
prefer a similar syntax to a completely new one that would require a much
greater retrofit of existing SGML tools. The above syntax could at least
be hacked by proper keyword declaration in the subset. The downside 
is of course the presence of the currently SGML-illegal content in the
MS status keyword specification, but this seems somewhat minor.

Murray

...........................................................................
Murray Altheim, SGML Grease Monkey                  <altheim[@]eng.sun.com>
Member of Technical Staff, Tools Development & Support
Sun Microsystems, 2550 Garcia Ave., MS UMPK17-102, Menlo Park, CA 94043 USA
         "Give a monkey the tools and he'll build a typewriter."

Received on Thursday, 5 June 1997 14:29:36 UTC