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


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] XSLT 2.0 and XSL(-FO) 2.0

[ Lists Home | Date Index | Thread Index ]

Hi Ron,

>> It would make a lot more sense to have this dictated within the
>> stylesheet, which then governs the way in which the source document
>> is parsed (whether validation is carried out; what happens as a
>> result of validation errors) rather than by the source document.
> This seems like an awfully XSLT-centric view of the world.

Would I have any other? ;)

> I'm sure it's useful in many cases, but it seems that in the general
> case the application, not the stylesheet, should control this.

I think that we agree, though I can see it might not have sounded like

Random terminology definition -- when I talk about "XSLT processors"
I'm talking about the code that takes a PSVI and does a transformation
into a node tree. When I talk about "XSLT applications" I'm talking
about XSLT processors that are invoked on a URI and therefore also
govern the parsing process -- taking the document and creating a PSVI.

An XSLT application is typically controlled purely by a stylesheet.
You might have some command-line options that override particular
options, but basically people want to be able to control the whole
process, from beginning to end. All they have to do is specify the URI
of the source document, and the place where they want the result to
go, and that's it.

In that common case, the application is the XSLT application, and the
configuration of that XSLT application is the stylesheet. So when I
say that the schema location should be dictated by the stylesheet, I'm
actually saying that it should be dictated by the application.

The important distinction is between the following two situations:

  - The XSLT application is in control. Through some mechanism it is
    supplied a schema that it can use to create a PSVI from the
    document. One such mechanism, for standalone command-line XSLT
    applications that are purely controlled through a stylesheet,
    would be that the stylesheet contains a reference to the schema,
    and the XSLT application uses that as its instruction for what
    schema to use.

  - The document is in control. It points to a schema, and the XSLT
    application has to use the referenced schema to create the PSVI
    from the document.

What I'm arguing is that, unless you're working in a highly
constrained environment (i.e. not the Internet), the second case is
dangerous, for two main reasons:

  - The XSLT application can't guarantee that the schema referenced by
    the document will be available. On the other hand, a schema
    referenced by an XSLT application is part of the XSLT application
    and therefore guaranteed to be available.

  - The XSLT application can't guarantee that the schema referenced by
    the document bears any relation to the schema that it's expecting
    to be referenced by the document. The fact a document is valid
    against that schema means nothing to the XSLT application. On the
    other hand, the content of the schema referenced by an XSLT
    application is known by the XSLT application, so knowing that a
    document is valid according to that schema is worth quite a lot.

(These arguments are used with DTDs as well; well-designed XSLT
stylesheets don't rely on a particular DTD being available and encode
any vital validity checks within the stylesheet itself.)

Of course an XSLT processor might be used separately from an XSLT
application -- it might be used as part of the transformation pipeline
in Cocoon, say. In these cases, the PSVI just appears out of nowhere,
so the XSLT processor doesn't have to worry about what schema to use
with it.

XSLT stylesheets control both the core XSLT processing and the default
behaviour of an XSLT application (through the xsl:output element), and
I think it should continue to do so (though making the distinction
clearer would be a good thing, in my opinion).



Jeni Tennison


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

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