W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > December 2005

RE: Use cases

From: Fang, Andrew <afang@ptc.com>
Date: Tue, 20 Dec 2005 12:14:48 -0500
Message-ID: <A69AA663CE9BBC44AE1DA72483DE15DE01F2E228@HQ-MAIL3.ptcnet.ptc.com>
To: "Norman Walsh" <Norman.Walsh@Sun.COM>, <public-xml-processing-model-wg@w3.org>

We do have some use cases that use conditions, although not based on
error conditions, but parameter values, for example

1. Parse XML
2. Resolve query, validation, etc.
3. Determine stylesheet type (e.g. xsl vs. fosi) base on the input 
4. If xsl, do xsl transformation 
5. If fosi, return document back to application for further processing

A use case that requires passing parameters

1. Parse XML
2. Some processing
3. XSL transformation
4. Some post processing
5. According to output properties specified in XSL stylesheet, serialize
to file system accordingly.

Andrew


> -----Original Message-----
> From: public-xml-processing-model-wg-request@w3.org
[mailto:public-xml-
> processing-model-wg-request@w3.org] On Behalf Of Norman Walsh
> Sent: Tuesday, December 20, 2005 10:59 AM
> To: public-xml-processing-model-wg@w3.org
> Subject: Use cases
> 
> A survey of the use cases on my desktop boils down in the following
> way:
> 
> Most pipelines are simple, linear sequences. For example:
> 
>   1. Parse XML
>   2. Perform XInclude
>   3. Validate with RELAX NG
>   4. Validate with XSD
>   5. Transform
> 
> Some pipelines begin with non-XML sources, so stage 1 reads
> a non-XML source and produces XML:
> 
>   1. Read non-XML
>   2. Transform
> 
> Some pipelines produce ultimately non-XML results:
> 
>   1. Read pim.rdf
>   2. Transform
>   3. Produce sched.txt
> 
> Some pipelines have several non-XML steps:
> 
>   1. Read diagram.n3
>   2. Transform
>   3. Produce diagram.dot
>   4. Produce diagram.png
> 
> Some pipelines read several inputs:
> 
>   1. Parse 1.xml
>   2. Parse 2.xml
>   3. Transform 1.xml
>   4. Transform 2.xml (also using the output of stage 3)
> 
> Some pipelines have sub-pipelines:
> 
>   1. Read 1.n3; transform it; produce 1.svg
>   2. Read 2.n3; transform it; produce 2.svg
>   3. Read doc.xml
>   4. Transform doc.xml (incorporating 1.svg and 2.svg)
> 
> Some pipelines produce several outputs:
> 
>   1. Parse XML
>   2. Transform (producing 1.xml, 2.xml, ..., n.xml)
> 
> Some pipelines need to process all the outputs from a preceding stage:
> 
>   1. Parse XML
>   2. Transform (producing 1.xml, 2.xml, ..., n.xml)
>   3. Transform 1.xml
>      Transform 2.xml
>      ...
>      Transform 3.xml
> 
> Some stages have parameters (simple value parameters in addition to
> XML input file(s)). I don't think I have any use cases where one stage
> has to generate simple value parameters for a subsequent stage).
> 
> Although I can imagine wanting pipelines that handle conditionals and
> errors, all of the examples I have at hand don't have conditional
> processing and either succeed or fail.
> 
>                                         Be seeing you,
>                                           norm
> 
> --
> Norman.Walsh@Sun.COM / XML Standards Architect / Sun Microsystems,
Inc.
> NOTICE: This email message is for the sole use of the intended
> recipient(s) and may contain confidential and privileged information.
> Any unauthorized review, use, disclosure or distribution is
prohibited.
> If you are not the intended recipient, please contact the sender by
> reply email and destroy all copies of the original message.
Received on Tuesday, 20 December 2005 17:14:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:21:46 GMT