[pdal] Pipeline XML as primary channel?

[Michael Gerlek]

Actually the rules can be a bit tighter, I think, if we add a
FilterType and a MultiFilter type...

- Reader, Filter, and MultiFilter are all kinds of Stages
- a Writer is not a Stage, however

- Writers have exactly one Stage child
- Readers have zero Stage children
- Filters have exactly one Stage child
- MultiFilters have one or more Stage children

I'll make up some examples tomorrow.

.mpg

On Aug 18, 2011, at 5:28 PM, Pete Gadomski <pete.gadomski at gmail.com> wrote:

> All,
>
> Sorry, I needed to set maxOccurs="unbounded" in for Option elements.
> Attached is the updated .xsd
>
> Pete
>
> 2011/8/18 Pete Gadomski <pete.gadomski at gmail.com>:
>> Howard,
>>
>> I've attached an .xsd (and a validating .xml) for a possible pipeline
>> xml format.
>>
>> Cheers,
>> Pete
>>
>> On Thu, Aug 18, 2011 at 15:25, Michael P. Gerlek <mpg at flaxen.com> wrote:
>>> If we're going to push the xml a little further, I'd be inclined to relax my
>>> initial position that it needed to be read/written via the ptree xml
>>> serializer.
>>>
>>> I had the idea that we could serialize as json, etc, too, but I think it is
>>> more important that we have flexible XML reading/writing (such as using
>>> attributes and supporting xsd validation and such).
>>>
>>> -mpg
>>>
>>>
>>>> -----Original Message-----
>>>> From: Howard Butler [mailto:hobu.inc at gmail.com]
>>>> Sent: Thursday, August 18, 2011 2:03 PM
>>>> To: mpg at flaxen.com
>>>> Cc: 'Pete Gadomski'; pdal at lists.osgeo.org
>>>> Subject: Re: [pdal] Pipeline XML as primary channel?
>>>>
>>>>
>>>> On Aug 17, 2011, at 5:40 PM, Michael P. Gerlek wrote:
>>>>
>>>>>> `//Filter[@type="filters.reprojection"]` seems cleaner than
>>>>>> `//Filter/Type[text()="filters.reprojection"/..`.
>>>>>
>>>>> Wow, they both just look like so much @$#^@%$//! line noise to me...
>>>>> :-)
>>>>>
>>>>>> * <opinion>Attributes work well for atomic values e.g. driver types
>>>>>> and option names.</opinion>
>>>>>
>>>>> <opinion assertedas="fact">Agreed.</opinion>
>>>>>
>>>>>> <WriterPipeline>
>>>>>>    <Writer type="drivers.oci.writer">
>>>>>>        <Option name="debug">true</Option>
>>>>>>        <Reader type="drivers.las.reader">
>>>>>>            <Option name="filename">in.las</Option>
>>>>>>        </Reader>
>>>>>>    </Writer>
>>>>>> </WriterPipeline>
>>>>>
>>>>> Yup, that's basically what I had when I started the project -- but
>>>>> then I found out that boost::property_tree doesn't serialize to XML
>>>>> attrs quite as cleanly as I'd like.  I'm going to revisit that issue
>>>>> this afternoon, I think.
>>>>
>>>> I agree that our pipeline XML isn't optimal, and we should move it toward
>>>> something sane earlier rather than later.  Pete, when you get some time,
>>> can
>>>> you help me cook up an XSD that we can use to externally validate our
>>>> pipelines?  I'll work to implement it.
>>>>
>>>> Howard=
>>>
>>>
>>
>
> <writerpipeline.xsd>