Re: 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.
> 
... choices I don't like ...
> 
> 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.
> 

This is much perferred.  The decision to include/exclude is either
based on information at the server or information at the client.  If
the former, then a server side script can evaluate it before
generating the final XML, and then it's not really a language issue
(or at least can be finessed).  If it's based on client information,
then we need to assume there's a way for the processor to find and
evaluate that information - such as the value of "%noframe;" or
whatever.  This is not a language issue.  If we take the element
approach, then we throw it back into the application's domain, or to
some middle-layer (perhaps the DOM group's).  Namespaces would work
well with a layered approach.


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

Sure, but isn't that also an issue for the Document Object Model?

> Another item for the post-July-1 priority queue.  Seems like an
> obvious huge interoperability win to me.
> 
I'm not sure this is true if MS & NS develop conflicting versions of
the local environment.

Matthew
matt@wdi.disney.com

Received on Thursday, 5 June 1997 12:37:34 UTC