- From: Innovimax SARL <innovimax@gmail.com>
- Date: Wed, 7 Feb 2007 18:48:31 +0100
- To: "Alex Milowski" <alex@milowski.org>
- Cc: public-xml-processing-model-wg@w3.org
Fellows, Ok so let me add my 5 cents. This is supposed to work for component defined by the WG (in core or elsewhere) But what about component used defined ? This implies AFAIK that user defined components won't have access to "component parameters" (as opposed to "instance parameters" to pass trough to the component). This is from my point of vue a serious limitation for V.next. Moreover, is there really no use case for component to have complex (as opposed to simple, as simpleType) "component parameters" ? In those case, if they exists, and I supposed they do, the attribute will be a serious limitation. Then, it will look like <p:xslt, will have similar look as <p:for-each or <p:choose which is a bit annoying. Furthermore, for authoring tool, it won't be so easy to move from a component call to another, especially from a core one (p:xslt) to a user defined one (p:step name="my:xslt") and vice versa. Cheers, Mohamed On 2/7/07, Alex Milowski <alex@milowski.org> wrote: > > > On 2/6/07, Norman Walsh <Norman.Walsh@sun.com> wrote: > > A couple of recent threads have indicated support for a sort of > > chameleon component that I'd just assumed we wouldn't touch with a ten > > foot pole. > > > > If > > > > <p:step type="validate">...</p:step> > > > > can do one of several different kinds of validation (XSD, RNG, SCH) > > and > > > > <p:step type="xslt">...</p:step> > > > > can perform either XSLT 1.0 or XSLT 2.0 transformations, then I > > think we have a clear need for two different types of parameters > > (which I'd been hoping, perhaps naively, that we could avoid). > > > > If we're going to go this way, I wonder if it's worth revisiting the > > names of components. Using the types as the GIs would give us two > > places to put parameters: on the element or in a p:parameter. > > > > <p:validate language="http://www.w3.org/2001/XMLSchema > "> > > ... > > </p:validate> > > > > and > > > > <p:xslt version="2.0"> > > <p:param version="1.2"/> > > ... > > </p:xslt> > > > > would be unambiguous. > > > > Personally, having step types identified by the element name would be much > better as we could use attributes to configure the step. That would allow > differentiation between step configuration (e.g. schema language or > XSLT version) and parameters to that invocation (e.g. stylesheet > parameters). > > This is certainly inline with many other well known "process control" > languages (e.g. ant). > > In the end, the only issue becomes pipeline validation. In XML Schema, you > can > solve this using a substitution group. Relax has a similar mechanism. As a > pipeline > "knows" its built-in components, that isn't as much of a problem to > configure > the schema. > > In XSLT, extension namespaces are identified in some way. If we did a > similar thing, > a pipeline processor would know the difference between a step and some > random > markup for documentation or other purposes. > > -- > --Alex Milowski > "The excellence of grammar as a guide is proportional to the paucity of the > inflexions, i.e. to the degree of analysis effected by the language > considered." > > Bertrand Russell in a footnote of Principles of Mathematics -- 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 Wednesday, 7 February 2007 17:48:54 UTC