W3C home > Mailing lists > Public > public-xml-core-wg@w3.org > December 2004

Re: FW: XInclude use case for Device Independence

From: Norman Walsh <Norman.Walsh@Sun.COM>
Date: Tue, 21 Dec 2004 11:00:35 -0500
To: public-xml-core-wg@w3.org
Cc: Rotan Hanrahan <Rotan.Hanrahan@MobileAware.com>
Message-id: <87pt133al8.fsf@nwalsh.com>
/ Paul Grosso <pgrosso@arbortext.com> was heard to say:
| With permission, I am forwarding this to the XML Core WG
| mailing list.  Please include Rotan Hanrahan on the cc line
| in any replies.

Sigh. This is really a question of the processing model which has no
home since it was removed from the Core WGs charter.

| I'm reporting on an idea and a "difficulty" related to XInclude from the
| DIWG, and I'm seeking some comments from people more familiar with the
| use and direction of XInclude, which I will subsequently report to DIWG.
| At a DIWG face-to-face some weeks ago, the possibility of using XInclude
| with DISelect [1] was discussed. This presents an interesting use case
| whereby DISelect provides a content negotiation function, and XInclude
| acquires the content selected via DISelect.
| Among the many illustrative cases, we considered the following:
| <?xml version='1.0'?>
| <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
| "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
| <html
|  xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"
|  xmlns:xi="http://www.w3.org/2001/XInclude">
|  xmlns:sel="http://www.w3.org/2004/CSelection">
|   <head><title>News</title></head>
|   <body>
|     <h1>Top Story</h1>
|     <sel:select>
|       <sel:when sel:expr="dc:cssmq-width('px') &gt; 200">
|         <xi:include href="/full_story.xyz?date=EXPRESSION_GOES_HERE"/>
|       </sel:when>
|       <sel:otherwise>
|         <xi:include href="/small_story.xyz?date=EXPRESSION_GOES_HERE"/>
|       </sel:otherwise>
|     </sel:select>
|   </body>
| </html>
| In this case we used DISelect to choose a suitable version of a news
| story. The selection is based on the pixel width of the screen similar
| to the approach used in CSS Media Queries. This is a simple template
| mechanism. However, the href of the XInclude requires a parameter to be
| passed to the process. We have illustrated this as a "date" value
| determined by an expression. We have considered the possibility of using
| XPath expressions within the href attribute, but currently the XInclude
| proposal only supports escaping of characters. It does not support any
| form of "evaluation" of the href.
| Can you advise on any alternative strategy that might be adopted to
| facilitate the passing of evaluated parameters to URLs referenced by
| XInclude markup?

I don't think there's anything you can do to get XInclude to perform
any evaluation for you. That's just a URI as far as its concerned.

It seems to me that you need some other step in your processing model
to perform the evaluation and that step can finess XInclude.

Consider the following:

<?xml version='1.0'?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
 xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"
    <h1>Top Story</h1>
      <sel:when sel:expr="dc:cssmq-width('px') &gt; 200">
        <xsl:element name="xi:include">
          <xsl:attribute name="href"
        <xsl:element name="xi:include">
          <xsl:attribute name="href"

If you run that through an XSLT processor then run the result document
through an XInclude processor, you'll get the result you want.

Alternatively, you could invent an expression language and say that
your processing model is: load the document with XInclude suppressed,
evaluate the expressions, and then apply an XInclude processor.

| One alternative proposed at the meeting was an extension to DISelect
| that would mimic (or map to) XInclude but would permit XPath expressions
| to create the href attribute value. This would, however, create a new DI
| variant of XInclude and we would need to keep the DI version of XInclude
| in step with the official version of XInclude. This idea does not
| attract much support, so we are seeking advice on how to proceed.

If you decide to go that route, I think you should probably define the
semantics along these lines: AVTs in the di:include element are
evaluated and then the element is renamed xi:include and processed per
normal XInclude processing. But it's definitely ugly.

| Any advice or guidance you can offer us would be most welcome, and feel
| free to share this request with whoever you deem may be best suited to
| offer support.

As near as I can tell, you're going to have to come to grips with some
sort of processing model that allows you to either create xi:include
elements or load them without processing them and then process them.

                                        Be seeing you,

Norman.Walsh@Sun.COM / XML Standards Architect / Sun Microsystems, Inc.
NOTICE: This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.

Received on Tuesday, 21 December 2004 16:01:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:34 UTC