Re: State of XProc: language and community

On Mar 7, 2011, at 3:14 AM, <vojtech.toman@emc.com> <vojtech.toman@emc.com> wrote:
> Tony,
>  
> Few comments from me:
>  
> * Better separation – I can agree with you to a certain extent, but I personally never had problem with this. I joined the WG after this was already this was already in the language, but my personal understanding was that they just did the same that XSLT does (with xsl:output, xsl:mode, xsl:param, xsl:with-param etc.)


Definitely true.  This is definitely a mental thing.  Here's why it bothers me less in XSL than it does in XProc:

Flow
In XSL, there is no default “flow”.  It is determined by the source XML document.  
In XProc, there is a default flow.  That is, the steps are executed in the order they are in the pipeline.  You can deviate if you like, but the default seems to change my perception in some way that is difficult to describe in words, but is nonetheless significant.
Step Names
In XSL, after the “beginning” stuff out of the way, there's a small number of elements that repeat over and over.  (They are almost all <xsl:template>s and <xsl:function>s.)  

When visually scanning through an XSL document, this makes it easy to tell whether you are in the “main part” and “not main part”.

In XProc, after the “beginning” stuff is out of the way, there's a large number of different elements that occur at the same level.  I'm again struggling to nail down the super-specifics in words, but there is something about XProc that makes reading it a little more difficult than XSL.  That is why I think it could do with something akin to the <head>/<body> pattern of XHTML. 


> * Redundant steps – The problem with merging the different validate steps into one is that they have different options that are specific to the underlying schema language. Also the semantics is quite different in some cases, and so are the expected results (p:validate-with-xml-schema may return a document with PSVI annotations, p:schematron returns also the SVRL report document etc.) I personally believe that having three separate validation actually makes things easier for the user. Having one steps should be possible, but the complexity would move somewhere else and would be, IMHO, more difficult to explain.

This is extremely informative.  Thank you!

Perhaps the different validation steps do make things easier.  But what would you say to the following?

	<p:validate use="relax-ng">
		<p:input port="source">…</p:input>
		<p:input port="schema">…</p:input>
		<p:output port="result" />
	</p:validate>

…or…

	<p:validate>
		<p:input port="source">…</p:input>
	
		<p:input port="xsd">…</p:input>
		<p:input port="relax-ng">…</p:input>
		<p:input port="schematron">…</p:input>

		<p:output port="xsd" />	
		<p:output port="result-relax-ng" />
		<p:output port="result-schematron" />
	</p:validate>

Would that be confusing?  

I'm not trying to be difficult, and in fact your point makes things much clearer for me.  I just feel compelled to at least explore a few alternative rough ideas and getting feedback before moving on.


>  * Lack of syntactic sugar – I think most will agree with you. You already referred to the XProc wiki. The WG is well aware of the list of proposed XProcVNext features, and *if* there is ever a next version of XProc, it will most certainly incorporate many of the convenience features proposed there.


w00t!  :D


>  * Data types – Yep.


Double w00t!  :D  :D


>  * Javadoc for XProc – I have actually written (in XProc ) a tool like that: https://community.emc.com/docs/DOC-8657


Ooooh!  Thank you for the link.  I am going to go check it out right now!  :)


—Tony

Received on Tuesday, 8 March 2011 15:07:58 UTC