W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > February 2007

Re: Chameleon components

From: Innovimax SARL <innovimax@gmail.com>
Date: Sun, 18 Feb 2007 23:01:27 +0100
Message-ID: <546c6c1c0702181401v7aa5d9aes14eb6428eb6dadc1@mail.gmail.com>
To: "Jeni Tennison" <jeni@jenitennison.com>
Cc: public-xml-processing-model-wg@w3.org

Thanks Jeni,

Of course presented this way, all seems clearer :-)

But, going further with your proposition
Could we try to start a list of component that could be available
sooner or later regarding what is available today ?

Some of them will need to be in the core, other would need to be in a
separate spec, and other should just be given them a name to be sure
their will be not too much contradiction for their implementation. (Of
course, some of them are not listed as requirements of Xproc WG, but
for broader audience we should take care of them).

Here is a start of a list (which could be after discussion put into a
wiki page so as to grow slowly)

==Validation ==


and also existing

p:dtd (because a lot of DTD are still available and because it is
still possible to use SGML DTD with infosets and because of extended
iso:nvdl (which would have multiple outputs)
oasis:ubl (because of lack of full validation through existing
validation language)

And what about compound validations (relax+schematron, schema+schematron)
And what about schema validation itself (validate XML Schema, validate
Relax Schema, because of their non ability at being validated against
other schema)


p:xslt (implying XSLT v 1.0 and XSLT v 1.1)
p:xslt2sa (schema aware, with backward compatibility to 1.0, but not 1.1)
p:xslt2b (basic non schema aware, with backward compatibility to 1.0,
but not 1.1)

optional but which could need some help to achieve interoperability

p:xproc (to run a dynamically generated pipeline)

In the future
xquery with extension (update, scripting, etc.)

and going further giving a recommendation to implementors to expose
API in SAX and DOM (and why not stax) in the step declaration language


Of course, everybody would tell that it is seriously out of scope for
V1, but trying to make without knowing we will have to tackle with
them in V.next is not even serious



On 2/18/07, Jeni Tennison <jeni@jenitennison.com> wrote:
> Hi,
> Here's me weighing in... It seems to me that there are two separable
> issues being discussed here:
> 1. Should we have (a) components such as "p:transform" and "p:validate"
> which act as interfaces to multiple applications, with configuration
> parameters that choose between them or (b) separate components for
> separate applications such as "p:xslt", "p:xslt2b", "p:xslt2sa",
> "p:xmlschema", "p:relaxng".
> So, on 1:
> I think it's a mistake to bundle multiple applications into a single
> component (i.e. have "p:transform" and "p:validate" steps) because they
> have completely different interfaces. XSLT 1.0 produces a single result
> document; XSLT 2.0 produces many. RELAX NG can check "plausible
> validity"; XSD takes multiple schema documents; Schematron has a 'phase'
> parameter; and so on.
> We will end up with a situation where we have huge numbers of optional
> parameters, parameters that are ignored in certain circumstances, inputs
> that must have only one document if a particular application is
> specified and so on. In other words, lots of constraints that can only
> be expressed through fairly complicated natural language.
> We will also end up having components whose definitions will have to
> change as new schema and transformation languages emerge. For example,
> "p:validate" will have to handle XML Schema 2.0 at some point. I think
> this will cause big headaches.
> Cheers,
> Jeni
> --
> Jeni Tennison
> http://www.jenitennison.com

Innovimax SARL
Consulting, Training & XML Development
9, impasse des Orteaux
75020 Paris
Tel : +33 8 72 475787
Fax : +33 1 4356 1746
RCS Paris 488.018.631
SARL au capital de 10.000 
Received on Sunday, 18 February 2007 22:01:38 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:32:41 UTC