- From: Tim Bray <tbray@textuality.com>
- Date: Thu, 05 Jun 1997 08:51:53 -0700
- To: w3c-sgml-wg@w3.org
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