cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <vadim.gritse...@verizon.net>
Subject Re: [RT] Views for readers
Date Thu, 14 Aug 2003 18:23:50 GMT
Miles Elam wrote:

> Sylvain Wallez wrote:
>
>> Go back to first post of this thread, where (last paragraph) I 
>> proposed something similar. The whole discussion is about how we 
>> could have a syntax which doesn't introduce such verbosity in the 
>> sitemap. 
>
>
>
> Verbosity is not necessarily a bad thing.  If it were, would any of us 
> be using XML?  ;-) 


Good point.

<snip/>


>> Let's consider the MIDI example. Suppose we have a large collection 
>> of karaoke files (MIDI supports embedded text that can be played on 
>> screen while playing the music), and we want to index the text of 
>> these songs for easy retrieval (along with some other meta-data).
>>
>> Here's a sitemap example, using the current syntax 
>

<snip/>

>> And the proposed shorter one :
>>
>> <map:match pattern="*.mid">
>>  <map:read src="{1}.mid" unless-label="content"/>
>>  <map:generate type="midi" src="{1}.mid"/>
>>  <map:transform src="xmidi2xdoc.xsl" label="content-label"/>
>>  <!-- should never come here -->
>>  <map:serialize type="xml"/>
>> </map:match>
>

Two lines. What does it give except obfuscation? Given the point above 
("Verbosity is not necessarily a bad thing" (c) Miles Elam) more 
readable and already supported syntax is:

 <map:resource name="midi"/>
  <map:match type="view" pattern="content">
    <map:generate type="midi" src="{1}.mid"/>
    <map:transform src="xmidi2xdoc.xsl" label="content"/>
    <map:serialize type="xml"/>
  </map:match>
  <map:read mime-type="whatever/midi" src="{1}.mid"/>
 </map:match>

 <map:match pattern="*.mid"/>
  <map:call resource="midi"/>
 </map:match>

Moreover! Resource "midi" is reusable:

 <map:match pattern="another/*.mid"/>
  <map:call resource="midi"/>
 </map:match>

, while example above is not.



> This breaks current convention that either a reader or a 
> generator/transformer/serializer can act in a pipeline.


And, given this resource example, it does not break any sitemap 
semantics which we have today.



> In the first example, if "content" isn't specified, the action returns 
> null and the reader is invoked;  As far as the pipeline logic is 
> concerned, there is only the reader.  Serializers are already known as 
> universal exit points.  To use the second, the convention must be 
> broken and readers must become universal exit points.
>
> In other words,
>
> <map:match pattern="*.mid">
> <map:read src="{1}.mid"/> <!-- without the unless-label -->
> <map:generate type="midi" src="{1}.mid"/>
> <map:transform src="xmidi2xdoc.xsl" label="content-label"/>
> <!-- should never come here -->
> <map:serialize type="xml"/>
> </map:match>
>
> must become valid for consistency.  A reader becomes an exit point and 
> the rest of a pipeline is, by default, ignored.  Is this an intended 
> consequence?


I fell strongly "-1" on this one.

Vadim



Mime
View raw message