Re: Chameleon components

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 ==

p:schema
iso:relax
iso:schematron

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
DTD in DSDL)
iso:nvdl (which would have multiple outputs)
oasis:ubl (because of lack of full validation through existing
validation language)
iso:relax_with_dtll



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)

==Transformation==

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)
p:xquery

optional but which could need some help to achieve interoperability

p:xproc (to run a dynamically generated pipeline)
p:xpath2
old:sqlx
old:balise
iso:dsssl
sf:stx
stilo:omnimark
orbeon:xpl
apache:cocoon
apache:ant
inria:xstream
inria:cduce

In the future
schema2
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

implement:expose-as-sax
implement:expose-as-stax
implement:expose-as-dom

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

Regards,

Mohamed


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
http://www.innovimax.fr
RCS Paris 488.018.631
SARL au capital de 10.000 €

Received on Sunday, 18 February 2007 22:01:38 UTC