- From: Matthew Fuchs <matt@wdi.disney.com>
- Date: Thu, 5 Jun 97 9:39:27 PDT
- To: tbray@textuality.com (Tim Bray)
- Cc: 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. > ... 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