OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: XLink embedding (was Re: W3C XML Schema best practice : inclusions)

[ Lists Home | Date Index | Thread Index ]
  • From: Didier PH Martin <martind@netfolder.com>
  • To: uche.ogbuji@fourthought.com
  • Date: Wed, 13 Dec 2000 10:56:10 -0500

Hello Uche

Uche said:
Eh what?  I don't think it's a good idea to override the server's specified
TTL.  If the provider doesn't know how to use HTTP, it's a problem you
take up with them.  Any service provider that set their TTL to 0 in a
misguided attemp to improve hit count, or any other such trickery would
probably eventually get yelled at by users.
Even if this is something you _absolutely_ have to have this override in the
consumer, I think that is a highly application-specific matter that should
be addressed by the XInclude or XLink.

Didier replies:
Why is this a wrong idea? practically speaking a lot of content's TTL is not
well set. If, for instance, you need to aggregate contents to create a
portal, then you'll probably will have to set the TTL yourself otherwise,
the time required to get the content is too long. But you are right, the
publishers are supposed to do their job right and to define caching
mechanism in recommendations is not necessarily a good idea (like saying to
somebody that he's not doing his job well :-) However, practically speaking
it is needed for some kind of application needing to aggregate contents.
Anyway, a particular app may inherit the xinclude behavior and add the
caching override. Good point Uche.

Uche said:
Is this realistic to expect?  It's certainly hard to imagine this scenario
with XSLT stylesheets, since XSLT processing tends to be highy non-linear.
It's certainly possible with CSS, but are the saving worth the processing
complexity in the user agent?

Didier replies:
Wrong, it is possible with XSLT - I did it in my labs, and it is working
very well. The only problem today is that the transformation scope is for
the entire document. To limit the scope to a fragment may help to have the
inclusion/transformation to occur in parallel. Off course this applies only
the xinclude construct, not to the xlink construct since the inclusion
(show="embed") occurs only when the user clicks on the link. Off course, a
lot of actual XML processing will have some problems with parallel
processing, but this is an implementation issue not an XSLT language issue.
Inclusions/transformation may be performed in parallel. By the way, to limit
the scope of transformation to a document fragment brings the notion of
document component. For instance, I can request a web service for a calendar
to be embedded in my XHTML document. If we limit the transformation to this
inclusion, we embed a component. For instance, the calendar data may be
displayed as a table (month view), as a list (day view). Also, when we think
inclusion/transformation, we also have to think about partitioning, can we
partition the processes on the requester or on the provider?  Transformation
may be partitioned on the basis of different parameters like the business
model, processing capabilities, etc.. in conclusion, yes it make sense - in
the case of inclusion - to perform a transformation at a document fragment
level and this can occur in parallel (only if the transformation scope is at
the document fragment level and limited to the included content, not
including the host document)

Uche said:
Sounds as if this could be at least partly handled by content-negotiation at
the transport layer.  maybe it would be nice to have an extension mechanism
for transport-level parameters in inclusions and linking.  Then my
implementation could extend the spec to support a set of http-header
attributes in the origin element that are tacked on the the HTTP request

Didier said:
We have CC/PP as a work in progress (http://www.w3.org/Mobile/CCPP/) but no
ways to use that in the context of inclusions. The inclusion may be based on
the device capabilities. The data included may not be pertinent on certain
devices. The problem though is to state that this inclusion is to occur only
for certain devices. This is obviously more for xinclude than it is for

Didier PH Martin
Email: martind@netfolder.com
Conferences: xml devcon 2000 (http://www.xmldevcon2000.com)
		 Wireless Summit NY (http:www.pulver.com)
	       xml devcon 2001 London (http://www.xmldevcon2000.com)
Book: XML Professional (http://www.wrox.com)
column: Style Matters (http://www.xml.com)


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS