<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Top-Down Modeling and BPMN Subprocesses</title>
	<atom:link href="http://www.brsilver.com/2006/12/15/top-down-modeling-and-bpmn-subprocesses/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.brsilver.com/2006/12/15/top-down-modeling-and-bpmn-subprocesses/</link>
	<description>Bruce Silver on business process management</description>
	<lastBuildDate>Thu, 09 Feb 2012 22:38:20 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
	<item>
		<title>By: nickbroom</title>
		<link>http://www.brsilver.com/2006/12/15/top-down-modeling-and-bpmn-subprocesses/comment-page-1/#comment-309</link>
		<dc:creator>nickbroom</dc:creator>
		<pubDate>Sun, 06 Sep 2009 11:15:09 +0000</pubDate>
		<guid isPermaLink="false">http://www.brsilver.com/2006/12/15/top-down-modeling-and-bpmn-subprocesses/br#comment-309</guid>
		<description>I know that this thread is now quite old, but comparing this to Bruce&#039;s book it looks like its gone with the gateway option? I have to admit favouring this option as well from the point of view of a business user understanding it.

I also prefer it based on (a definition I read somewhere but can&#039;t recall) the fact that the gateway in this instance is evaluating process data to determine the path to take. Business people will understand the input and output concept demonstrated by the gateway more readily than they may do the error event. I also recall in the book that Bruce states that gateways are best used to model business exceptions versus the use of error events to denote service task exceptions (I hope I&#039;ve paraphrased that correctly, but apologies if I haven&#039;t).</description>
		<content:encoded><![CDATA[<p>I know that this thread is now quite old, but comparing this to Bruce&#8217;s book it looks like its gone with the gateway option? I have to admit favouring this option as well from the point of view of a business user understanding it.</p>
<p>I also prefer it based on (a definition I read somewhere but can&#8217;t recall) the fact that the gateway in this instance is evaluating process data to determine the path to take. Business people will understand the input and output concept demonstrated by the gateway more readily than they may do the error event. I also recall in the book that Bruce states that gateways are best used to model business exceptions versus the use of error events to denote service task exceptions (I hope I&#8217;ve paraphrased that correctly, but apologies if I haven&#8217;t).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: franzi</title>
		<link>http://www.brsilver.com/2006/12/15/top-down-modeling-and-bpmn-subprocesses/comment-page-1/#comment-308</link>
		<dc:creator>franzi</dc:creator>
		<pubDate>Wed, 02 Sep 2009 13:42:45 +0000</pubDate>
		<guid isPermaLink="false">http://www.brsilver.com/2006/12/15/top-down-modeling-and-bpmn-subprocesses/br#comment-308</guid>
		<description>I like the exception handling. In my case it is a simple plausible or not question. But the problem is, that it occurs in a subprocess within a subprocess. In the case of not plausible the flow should jump out to the parent-parent-process, that is but two levels higher. I don&#039;t know, how this can be achieved with an error intermediate event.
With a link-event, yes.</description>
		<content:encoded><![CDATA[<p>I like the exception handling. In my case it is a simple plausible or not question. But the problem is, that it occurs in a subprocess within a subprocess. In the case of not plausible the flow should jump out to the parent-parent-process, that is but two levels higher. I don&#8217;t know, how this can be achieved with an error intermediate event.<br />
With a link-event, yes.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: BPMS Watch &#187; Modeling Business Exceptions in BPMN</title>
		<link>http://www.brsilver.com/2006/12/15/top-down-modeling-and-bpmn-subprocesses/comment-page-1/#comment-307</link>
		<dc:creator>BPMS Watch &#187; Modeling Business Exceptions in BPMN</dc:creator>
		<pubDate>Wed, 07 Mar 2007 01:47:05 +0000</pubDate>
		<guid isPermaLink="false">http://www.brsilver.com/2006/12/15/top-down-modeling-and-bpmn-subprocesses/br#comment-307</guid>
		<description>[...] Bruce Mayfield posts a comment on an old thread exploring different ways to model business exceptions in BPMN.  Since that original post I&#8217;ve worked out some best practices for different types of exceptions (business exceptions vs system faults, exception detected interanlly to the process vs signaled by external event, etc).  As a reminder that our BPMN training is now available from bpmessentials.com, it&#8217;s worth reprinting his comment here and showing the solution.  He writes: &#8230; I have been trying to model a new system in the government sector. We are building an automated system to verify new employers have workers&#8217; compensation insurance. Each day a new list of potential uninsured employers will be created, checked against another database to make sure a letter has not already been sent, and if a letter has not been sent, a letter will be generated and sent. We have identified that there will be the possiblity that there will be exceptions where the automated process is &#8221; not sure&#8217; whether to send a letter and will require review by a human to make a decision as to whether the letter should be generated and sent. In this context we consider this a different kind of exception process not related to an error that will terminate a flow but will result in a decision to flow a token down one of two different paths&#8230;. [...]</description>
		<content:encoded><![CDATA[<p>[...] Bruce Mayfield posts a comment on an old thread exploring different ways to model business exceptions in BPMN.  Since that original post I&#8217;ve worked out some best practices for different types of exceptions (business exceptions vs system faults, exception detected interanlly to the process vs signaled by external event, etc).  As a reminder that our BPMN training is now available from bpmessentials.com, it&#8217;s worth reprinting his comment here and showing the solution.  He writes: &#8230; I have been trying to model a new system in the government sector. We are building an automated system to verify new employers have workers&#8217; compensation insurance. Each day a new list of potential uninsured employers will be created, checked against another database to make sure a letter has not already been sent, and if a letter has not been sent, a letter will be generated and sent. We have identified that there will be the possiblity that there will be exceptions where the automated process is &#8221; not sure&#8217; whether to send a letter and will require review by a human to make a decision as to whether the letter should be generated and sent. In this context we consider this a different kind of exception process not related to an error that will terminate a flow but will result in a decision to flow a token down one of two different paths&#8230;. [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: bmayfield</title>
		<link>http://www.brsilver.com/2006/12/15/top-down-modeling-and-bpmn-subprocesses/comment-page-1/#comment-306</link>
		<dc:creator>bmayfield</dc:creator>
		<pubDate>Tue, 06 Mar 2007 15:41:55 +0000</pubDate>
		<guid isPermaLink="false">http://www.brsilver.com/2006/12/15/top-down-modeling-and-bpmn-subprocesses/br#comment-306</guid>
		<description>I am just a newbie, but I have been trying to model a new system in the government sector. We are building an automated system to verify new employers have workers&#039; compensation insurance. Each day a new list of potential uninsured employers will be created, checked against another database to make sure a letter has not already been sent, and if a letter has not been sent, a letter will be generated and sent. We have identified that there will be the possiblity that there will be exceptions where the automated process is &quot; not sure&#039; whether to send a letter and will require review by a human to make a decision as to whether the letter should be generated and sent. In this context we consider this a different kind of exception process not related to an error that will terminate a flow but will result in a decision to flow a token down one of two different paths (OR). Our discovery of analyzing the business requirements seems related to the discussion of the credit check scenario above. The business users understand gateways so option 1 seems like the best fit for us as the users have trouble with option 2 or option 3. Bruce, any chance you could post the final diagram you are leaning toward?

Thanks.
Bruce M.</description>
		<content:encoded><![CDATA[<p>I am just a newbie, but I have been trying to model a new system in the government sector. We are building an automated system to verify new employers have workers&#8217; compensation insurance. Each day a new list of potential uninsured employers will be created, checked against another database to make sure a letter has not already been sent, and if a letter has not been sent, a letter will be generated and sent. We have identified that there will be the possiblity that there will be exceptions where the automated process is &#8221; not sure&#8217; whether to send a letter and will require review by a human to make a decision as to whether the letter should be generated and sent. In this context we consider this a different kind of exception process not related to an error that will terminate a flow but will result in a decision to flow a token down one of two different paths (OR). Our discovery of analyzing the business requirements seems related to the discussion of the credit check scenario above. The business users understand gateways so option 1 seems like the best fit for us as the users have trouble with option 2 or option 3. Bruce, any chance you could post the final diagram you are leaning toward?</p>
<p>Thanks.<br />
Bruce M.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Patrice</title>
		<link>http://www.brsilver.com/2006/12/15/top-down-modeling-and-bpmn-subprocesses/comment-page-1/#comment-305</link>
		<dc:creator>Patrice</dc:creator>
		<pubDate>Tue, 02 Jan 2007 09:23:04 +0000</pubDate>
		<guid isPermaLink="false">http://www.brsilver.com/2006/12/15/top-down-modeling-and-bpmn-subprocesses/br#comment-305</guid>
		<description>Hi All,

First of All, happy New Year 2007!

I wold like to say it depends on how you want to design your process. Though I really don&#039;t like the Li nk event solution which is for me avoiding the problem and not bringing a solution!

The question here is where do I want to have the decision taken and how do I want my main process to behave in case of a &#039;No Credit&#039; situation.

The control is made within the subprocess &#039;Check Credit&#039; but I can say that either the decision is made within the subprocess or within my main process.

If the flow inside my sub process depends on that decision then the decision is definitely inside my subprocess (I have a gateway designed in my subprocess that will split the flow in 2). And now I have to decide how that subprocess will communicate that decision to my Main process. Two possiblities here, from the main process point of view I may consider this as an &#039;Error&#039; and here I am in the situation  of the Error IE or I want my main process to consider it as another normal flow (Fits with Proposal 1 which I will comment later).

Now, you can decide that the flow of your sub process is not constrained by the decision. This means I have no gateway inside my sub process but in the end, the communication with the main process is solved the sameway.

Regarding the proposal 1, i would say that the need of an explicit task to set some values into some variables depends on the nature of my sub-process. If my subprocess in an embedded one than I don&#039;t see the need to have such a task as information are supposed to be shared between the two processes. If my sub process is an independant one, than such a task must explicitily be designed as I need to explicitly design which information will be exchanged by the 2 processes.

Still on Proposal 1, why can&#039;t we just have 2 different end events in my sub process? It would make it clear for Business people that I have two ways to end my sub process and that none of the ways are considered as error.

On Solution 3 (Error Event) why can&#039;t I draw an Error End event in place of an Error IE linked to the End event? Does that mean The process is supposed to come back here once the error is solved?

Hope this helps,
Thanks and have a nice day,
Patrice</description>
		<content:encoded><![CDATA[<p>Hi All,</p>
<p>First of All, happy New Year 2007!</p>
<p>I wold like to say it depends on how you want to design your process. Though I really don&#8217;t like the Li nk event solution which is for me avoiding the problem and not bringing a solution!</p>
<p>The question here is where do I want to have the decision taken and how do I want my main process to behave in case of a &#8216;No Credit&#8217; situation.</p>
<p>The control is made within the subprocess &#8216;Check Credit&#8217; but I can say that either the decision is made within the subprocess or within my main process.</p>
<p>If the flow inside my sub process depends on that decision then the decision is definitely inside my subprocess (I have a gateway designed in my subprocess that will split the flow in 2). And now I have to decide how that subprocess will communicate that decision to my Main process. Two possiblities here, from the main process point of view I may consider this as an &#8216;Error&#8217; and here I am in the situation  of the Error IE or I want my main process to consider it as another normal flow (Fits with Proposal 1 which I will comment later).</p>
<p>Now, you can decide that the flow of your sub process is not constrained by the decision. This means I have no gateway inside my sub process but in the end, the communication with the main process is solved the sameway.</p>
<p>Regarding the proposal 1, i would say that the need of an explicit task to set some values into some variables depends on the nature of my sub-process. If my subprocess in an embedded one than I don&#8217;t see the need to have such a task as information are supposed to be shared between the two processes. If my sub process is an independant one, than such a task must explicitily be designed as I need to explicitly design which information will be exchanged by the 2 processes.</p>
<p>Still on Proposal 1, why can&#8217;t we just have 2 different end events in my sub process? It would make it clear for Business people that I have two ways to end my sub process and that none of the ways are considered as error.</p>
<p>On Solution 3 (Error Event) why can&#8217;t I draw an Error End event in place of an Error IE linked to the End event? Does that mean The process is supposed to come back here once the error is solved?</p>
<p>Hope this helps,<br />
Thanks and have a nice day,<br />
Patrice</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: bruce</title>
		<link>http://www.brsilver.com/2006/12/15/top-down-modeling-and-bpmn-subprocesses/comment-page-1/#comment-304</link>
		<dc:creator>bruce</dc:creator>
		<pubDate>Tue, 19 Dec 2006 16:28:24 +0000</pubDate>
		<guid isPermaLink="false">http://www.brsilver.com/2006/12/15/top-down-modeling-and-bpmn-subprocesses/br#comment-304</guid>
		<description>Vaclav,
I don&#039;t think Marlon would claim his solution was &#039;elegant&#039;, nor would I.  Nor scalable, either, in the way you mean.  I think the overriding test was understandability to business people, where it certainly is best of the lot.  For elegance and scalability, I think the Error event solution is best, where &#039;Error&#039; is interpreted as a general-purpose exception condition, business or technical.  But elegance is wasted on users who don&#039;t know what you&#039;re talking about.</description>
		<content:encoded><![CDATA[<p>Vaclav,<br />
I don&#8217;t think Marlon would claim his solution was &#8216;elegant&#8217;, nor would I.  Nor scalable, either, in the way you mean.  I think the overriding test was understandability to business people, where it certainly is best of the lot.  For elegance and scalability, I think the Error event solution is best, where &#8216;Error&#8217; is interpreted as a general-purpose exception condition, business or technical.  But elegance is wasted on users who don&#8217;t know what you&#8217;re talking about.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: VaclavSynacek</title>
		<link>http://www.brsilver.com/2006/12/15/top-down-modeling-and-bpmn-subprocesses/comment-page-1/#comment-303</link>
		<dc:creator>VaclavSynacek</dc:creator>
		<pubDate>Tue, 19 Dec 2006 10:32:46 +0000</pubDate>
		<guid isPermaLink="false">http://www.brsilver.com/2006/12/15/top-down-modeling-and-bpmn-subprocesses/br#comment-303</guid>
		<description>I quite like Marlon&#039;s solution. It&#039;s the most elegant of all suggestions.

Still it&#039;s not perfect as it really requires repeating stuff. I believe repetition in any model makes it much harder to maintain and keep consistent. Maybe not an issue in this simple example, but surely is in more complex ones.

Imagine the same example but with sub-sub-sub-processes in separated diagrams and many more conditions. Than one business analyst (maybe a different one than the original author!) one day decides to change &quot;Credit OK?&quot; condition to &quot;Credit OK or a long time customer?&quot; condition. He really has to change all the copy conditions, which he might not know about. If he forgets only one of them than some customers may be billed even if the item is out of stock or other weird disasters may happen.

So this solution might be the most elegant for Bruce&#039;s training, but does not scale to real world. I&#039;m sorry for posting another negative comment without a solution suggestion, but the discusion has not yet pleased my idealistic modeling point of view.</description>
		<content:encoded><![CDATA[<p>I quite like Marlon&#8217;s solution. It&#8217;s the most elegant of all suggestions.</p>
<p>Still it&#8217;s not perfect as it really requires repeating stuff. I believe repetition in any model makes it much harder to maintain and keep consistent. Maybe not an issue in this simple example, but surely is in more complex ones.</p>
<p>Imagine the same example but with sub-sub-sub-processes in separated diagrams and many more conditions. Than one business analyst (maybe a different one than the original author!) one day decides to change &#8220;Credit OK?&#8221; condition to &#8220;Credit OK or a long time customer?&#8221; condition. He really has to change all the copy conditions, which he might not know about. If he forgets only one of them than some customers may be billed even if the item is out of stock or other weird disasters may happen.</p>
<p>So this solution might be the most elegant for Bruce&#8217;s training, but does not scale to real world. I&#8217;m sorry for posting another negative comment without a solution suggestion, but the discusion has not yet pleased my idealistic modeling point of view.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: bruce</title>
		<link>http://www.brsilver.com/2006/12/15/top-down-modeling-and-bpmn-subprocesses/comment-page-1/#comment-302</link>
		<dc:creator>bruce</dc:creator>
		<pubDate>Mon, 18 Dec 2006 16:40:06 +0000</pubDate>
		<guid isPermaLink="false">http://www.brsilver.com/2006/12/15/top-down-modeling-and-bpmn-subprocesses/br#comment-302</guid>
		<description>Marlon,
Your argument is compelling.  I agree, insert the gateways, forget the variuble - ignored in simulation anyway (at least in my tool).  For business analysts it&#039;s the most understandable.  Thanks for the insight.</description>
		<content:encoded><![CDATA[<p>Marlon,<br />
Your argument is compelling.  I agree, insert the gateways, forget the variuble &#8211; ignored in simulation anyway (at least in my tool).  For business analysts it&#8217;s the most understandable.  Thanks for the insight.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: marlon_dumas</title>
		<link>http://www.brsilver.com/2006/12/15/top-down-modeling-and-bpmn-subprocesses/comment-page-1/#comment-301</link>
		<dc:creator>marlon_dumas</dc:creator>
		<pubDate>Mon, 18 Dec 2006 02:56:58 +0000</pubDate>
		<guid isPermaLink="false">http://www.brsilver.com/2006/12/15/top-down-modeling-and-bpmn-subprocesses/br#comment-301</guid>
		<description>Hi Bruce,
If the model is intended to subject matter experts (and not to app. developers), I would definitely go for option 1, but simplified. Do we really need to introduce a variable &quot;bad credit&quot;? I don&#039;t think so. We could just skip task B if the &quot;credit OK&quot; condition evaluates to &#039;no&#039;. Then, in the second gateway, instead of basing the condition on variable &#039;bad credit&#039;, we could just write again &#039;credit OK?&#039; In other words, we could use the same condition in both gateways. Of course, in this case we need to invert the yes and the no in the second gateway so that &quot;Check Stock&quot; and &quot;Fulfill Order&quot; are only performed if &quot;credit OK&quot; evaluates to yes.

The need for an explicit variable (&#039;bad credit&#039;) only surfaces at the implementation level. Let me here consider the YAWL system as a target implementation platform, because anyway standard BPEL does not have sub-processes. If you write down this process model in YAWL, you would indeed need to introduce a variable &#039;bad credit&#039; in YAWL (or a similar variable); then, somewhere in sub-process &quot;Check Credit&#039; you need to set this variable, so that it can be used outside the sub-process. But this is an implementation detail, of little value at the business analysis level.

We should remember that at the end of the day, BPMN is a language for high-level process modeling. At a more detailed level, we would use something like YAWL or BPEL, and this is where the details related to variable manipulation would surface out.

The third option is also OK, but I agree that &quot;error handling&quot; is not something every user of BPMN will be familiar with. Also, I agree with you that &quot;not credit OK&quot; is not an error, it&#039;s more an &quot;exception&quot;, but unfortunately, the BPMN spec calls an &quot;error&quot; something that should be called an &quot;exception&quot;.</description>
		<content:encoded><![CDATA[<p>Hi Bruce,<br />
If the model is intended to subject matter experts (and not to app. developers), I would definitely go for option 1, but simplified. Do we really need to introduce a variable &#8220;bad credit&#8221;? I don&#8217;t think so. We could just skip task B if the &#8220;credit OK&#8221; condition evaluates to &#8216;no&#8217;. Then, in the second gateway, instead of basing the condition on variable &#8216;bad credit&#8217;, we could just write again &#8216;credit OK?&#8217; In other words, we could use the same condition in both gateways. Of course, in this case we need to invert the yes and the no in the second gateway so that &#8220;Check Stock&#8221; and &#8220;Fulfill Order&#8221; are only performed if &#8220;credit OK&#8221; evaluates to yes.</p>
<p>The need for an explicit variable (&#8216;bad credit&#8217;) only surfaces at the implementation level. Let me here consider the YAWL system as a target implementation platform, because anyway standard BPEL does not have sub-processes. If you write down this process model in YAWL, you would indeed need to introduce a variable &#8216;bad credit&#8217; in YAWL (or a similar variable); then, somewhere in sub-process &#8220;Check Credit&#8217; you need to set this variable, so that it can be used outside the sub-process. But this is an implementation detail, of little value at the business analysis level.</p>
<p>We should remember that at the end of the day, BPMN is a language for high-level process modeling. At a more detailed level, we would use something like YAWL or BPEL, and this is where the details related to variable manipulation would surface out.</p>
<p>The third option is also OK, but I agree that &#8220;error handling&#8221; is not something every user of BPMN will be familiar with. Also, I agree with you that &#8220;not credit OK&#8221; is not an error, it&#8217;s more an &#8220;exception&#8221;, but unfortunately, the BPMN spec calls an &#8220;error&#8221; something that should be called an &#8220;exception&#8221;.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: bruce</title>
		<link>http://www.brsilver.com/2006/12/15/top-down-modeling-and-bpmn-subprocesses/comment-page-1/#comment-300</link>
		<dc:creator>bruce</dc:creator>
		<pubDate>Sat, 16 Dec 2006 22:05:54 +0000</pubDate>
		<guid isPermaLink="false">http://www.brsilver.com/2006/12/15/top-down-modeling-and-bpmn-subprocesses/br#comment-300</guid>
		<description>Thanks for the responses so far. Vernon, I&#039;m counting you as a vote for the Error event. I have a problem with Cancel, since this isn&#039;t really a transactional subprocess; the goal is not to compensate activities inside the subprocess but abort the parent process. Also Cancel is supposed to be linked to a transaction manager such as WS-Transaction. Yeah, as if anyone has implemented that one. But that&#039;s ok, I&#039;m counting you as one vote for the intermediate event.

Steinar, I&#039;m counting yours as a vote for the gateway. I should have shown the end event after the gateway. Any end event will do.  In this case Terminate would not make any difference, since nothing is happening in parallel that needs to be killed. But I agree if there were other activities concurrent with the gateway, Terminate would be appropriate.

Vaclav, I agree with your comment re vagueness in the spec if gateway has multiple sequence flows in and and multiple out -- in fact I previously posted that was illegal but a reader wrote in to say it is allowed by the spec. In all other cases, it&#039;s pretty obvious what is a decision and what is a merge. My simulation engine has no problem with that at all.  So I&#039;m going to count your vote as against how BPMN has defined subprocesses. A legitimate point, but not too helpful to my immediate concerns.

Keep the comments coming in. You&#039;re helping me think about this.
--Bruce</description>
		<content:encoded><![CDATA[<p>Thanks for the responses so far. Vernon, I&#8217;m counting you as a vote for the Error event. I have a problem with Cancel, since this isn&#8217;t really a transactional subprocess; the goal is not to compensate activities inside the subprocess but abort the parent process. Also Cancel is supposed to be linked to a transaction manager such as WS-Transaction. Yeah, as if anyone has implemented that one. But that&#8217;s ok, I&#8217;m counting you as one vote for the intermediate event.</p>
<p>Steinar, I&#8217;m counting yours as a vote for the gateway. I should have shown the end event after the gateway. Any end event will do.  In this case Terminate would not make any difference, since nothing is happening in parallel that needs to be killed. But I agree if there were other activities concurrent with the gateway, Terminate would be appropriate.</p>
<p>Vaclav, I agree with your comment re vagueness in the spec if gateway has multiple sequence flows in and and multiple out &#8212; in fact I previously posted that was illegal but a reader wrote in to say it is allowed by the spec. In all other cases, it&#8217;s pretty obvious what is a decision and what is a merge. My simulation engine has no problem with that at all.  So I&#8217;m going to count your vote as against how BPMN has defined subprocesses. A legitimate point, but not too helpful to my immediate concerns.</p>
<p>Keep the comments coming in. You&#8217;re helping me think about this.<br />
&#8211;Bruce</p>
]]></content:encoded>
	</item>
</channel>
</rss>

