Fwd: Re: FW: how does XInclude mix with XML Schema? XSLT?

[Forwarded, the initial mails used the wrong WG email, Daniel]

:Date: Sat, 11 Sep 2004 00:48:00 +0200
:From: Daniel Veillard <daniel@veillard.com>
:Subject: Re: FW: how does XInclude mix with XML Schema? XSLT?
:To: Dan Connolly <connolly@w3.org>
:Cc: daniel@veillard.com, Jonathan Marsh <jmarsh@microsoft.com>,
:        public-xml-core@w3.org, www-xml-xinclude-comments@w3.org
:                       ^-wg missing

On Fri, Sep 10, 2004 at 05:19:03PM -0500, Dan Connolly wrote:
> On Sat, 2004-09-04 at 03:25, Daniel Veillard wrote:
> >   It is unclear what "XInclude used in XML Schemas" means.
> > That could mean XSD schemas using XInclude instead of xsd:include
> > to generate bigger schemas, and in that case I don't really see the
> > point.
> 
> It seems useful to make a test case for that situation and
> label it "don't do that; you're on your own if you do."
> 
> >  That could also mean XSD validating the result of an XInclude 
> > transformation but in that case what could be the problem, XInclude
> > generate an Infoset, and XSD works on an input infoset, I never heard
> > any problem with this.
> 
> Seems worth capturing the fact that it works in a test case.
> 
> >   For XInclude and XSLT, yes this is used, people are using XInclude
> > to assemble large documents, and combine the XInclude and XSLT pass,
> > this is available as xsltproc --xinclude flag for example. It works
> > since if this feature breaks in some way I get bug reports.
> 
> Again, that seems to merit a test case.

  Test cases for what ? I do not understand what you're aiming at.
Moreover it is more than a test case, it is a set of test inputs + 
and output + a way to describe the various non-xinclude related parts.
Those are features of a toolkit not of an XInclude processor. A normal
XInclude processor for example will not by default generate a correct
infoset for an XPath processor because for example it won't coalesce
adjacent CDATA section and text nodes. If you want to test XInclude
+ XSLT you have far more to do than setting up merely "a test case".
And this kind of more general testing is not an XInclude test, it doesn't
really test XInclude it test a framework.

  So I'm back at what are you aiming at ? If you think a test case 
as part of an XInclude test suite would demonstrate correct XInclude + XSLT
capabilities then I think it's plain wrong, there is far more to test
and a single test won't prove anything, just the opposite it may fool
people into believing they have proper support. I don't mean that 
(XInclude + XSLT) test suite would not make sense, just that it's outside
the scope of XInclude, and if done then must be done properly. Same
applies for XInclude + XSD and other combinations.

  Don't get me wrong, I'm all for test suites, but when I see:
    - that we don't have the XSLT test suite released (or I missed
      any announcemnt about it)
    - that the Schemas one seems to be far from clean 3 years after
      the release
i.e. that we don't have proper test suite for single big features, that
man power and interest is low in getting them and maintaining them,
I doubt it's a good idea to start to try to generate half baked cross
tests. A bad test suite is more dangerous than no test suite, and at
this point dilution of already scarce efforts doesn't sound wise to me.

Daniel

-- 
Daniel Veillard      | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
daniel@veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ |

Received on Saturday, 11 September 2004 12:10:53 UTC