<div>So what we have on the table is: to "read back" a WMS layer I need to gather this information from either a) a WMS GET Request b) a WMS PUT Request or c) a WMS PUT Request with optional inlined Image</div><div><br></div><div>The previous copies of OWS Context offered this information explicitly (Name, Title, SRS element, etc...), allowing me to get buy with just an XML parser (or in the case of javascript clients attacking a DOM).</div><div><br></div><div>Now I notice the current standard has some of this information pulled out (as noted in the previous email). I could hijack the standard and use the <b><id></b> element to hold the layer name, and go through the remaining standards and perform a similar "mapping".</div><div><br></div><div>What we need to facilitate discussion is a working example:</div><div><br></div><div><div><feed xmlns=“http://www.w3.org/2005/Atom”</div><div>   xmlns:owc=“http://www.opengis.net/owc/1.0”</div><div>   xml:lang=“en”></div><div>   ...</div><div>   <entry></div><div>     <b><id>http://someserver.com/#base</id></b></div><div>     <title>Base World Map</title></div><div>     ....</div><div>     <owc:offering code=“http://www.opengis.net/spec/owc/1.0/req/atom/wms”></div><div>       <owc:operation</div><div>         method=“GET”</div><div>         code=“GetCapabilities”</div><div>         href=“http://www.someserver.com/wrs.cgi?</div><div>             REQUEST=GetCapabilities&amp;</div><div>             SERVICE=WMS &amp;</div><div>             VERSION=1.1.1”/></div><div>       <ows:operation</div><div>         method="GET"</div><div>         code="GetMap"</div><div>         href="http://www.someserver.com/wrs.cgi?</div><div>             REQUEST=GetMap&amp;</div><div>             SERVICE=WMS&amp;</div><div>             VERSION=1.1.1&amp;</div><div>             layers=topp%3Aabse&amp;</div><div>             styles=&amp;</div><div>             srs=EPSG%3A4326&amp;</div><div>             bbox=-145.15104058007,21.731919794922,</div><div>                  -57.154894212888,58.961058642578&amp;</div><div>             width=780&amp;</div><div>             height=330&amp;</div><div>             format=image%2Fpng"/></div><div>     </owc:offering></div><div>   <entry></div></div><div><br></div><div><div>-- </div><div>Jody Garnett<br></div><div><br></div></div>
                 
                <p style="color: #A0A0A8;">On Wednesday, 20 February 2013 at 9:01 AM, Raj Singh wrote:</p>
                <blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
                    <span><div><div><div>You have to explain your point better for me. I understand that there are two distinct tasks here -- being a WMS client (an encoder) and being able to parse any WMS request into its parameters (a parser). And I understand that most clients are not also parsers. But if you want the additional capability of reading in the state of someone else's WMS map, how do you avoid needing to build a parser? Doesn't the additional code needed match up with the desired functionality? I thought we have asked for exactly the right amount of work ;)</div><div><br></div><div>---</div><div>Raj</div><div>The OGC: Making location count.</div><div><a href="http://www.opengeospatial.org/ogc/organization/staff/rsingh">http://www.opengeospatial.org/ogc/organization/staff/rsingh</a></div><div><br></div><div><br></div><div>On Feb 18, at 8:59 PM, Jody Garnett <<a href="mailto:jody.garnett@gmail.com">jody.garnett@gmail.com</a>> wrote:</div><div><br></div><blockquote type="cite"><div><div>So back to my origional feedback to Jim.</div><div><br></div><div>The conceptual model makes great re-use of existing standards, you can watch it call out to the other fish in the pond and it very carefully does not repeat anything making it easier to write as a standard.</div><div><br></div><div>If you swap perspective to that of an implementor you are left with … a gap of understanding.</div><div><br></div><div>The document produced by the ATOM Encoding requires client authors to implement both an encoder (so they can make request) and a parser so that they can understand the information that has been cleverly reused by the standards body.</div><div><br></div><div>This standard is lazy on the part of the standards body, and hostile to client authors.</div><div><br></div><div>As an example: Just because GeoTools has the ability to encode WMS requests, DOES NOT imply there is a ready-at-hand WMS request parser available.</div><div><br></div><div>As such the payload delivered by ATOM to describe a WMS request may as well be on the moon. Perhaps a bit further out of the payload is the content of a PUT request, or needs to call out for more schema information as with GML and WFS content.</div><div><br></div><div>So kudos on the reuse of definitions, missed the target audience when considering implementors (you have asked for too much work).</div><div>-- </div><div>Jody Garnett</div><div><br></div><div>On Tuesday, 19 February 2013 at 10:41 AM, Jody Garnett wrote:</div><div><br></div><blockquote type="cite"><div><div>Last time I looked at this one with Jim … I hated it (even though he was keen on how ATOM had been used).</div><div>For me It was not providing enough context for a client to make its own request.</div><div><br></div><div>I would really like to see a context document take shape, it would be very valuable between systems (which we tend to like on these osgeo lists).</div><div><br></div><div>Tracing through your links I arrive at some word docs, don't suppose you can format shift those to PDF or something more portable.</div><div><br></div><div>-- </div><div>Jody Garnett</div><div><br></div><div>On Tuesday, 19 February 2013 at 3:39 AM, Carl Reed wrote:</div><div><br></div><blockquote type="cite"><div><div>I am not sure if this group saw this announcement. This is a preliminary comment period. There will be another comment period later in the process.</div><div> </div><div>The announcement is here:</div><div> </div><div><a href="http://www.opengeospatial.org/node/1765">http://www.opengeospatial.org/node/1765</a></div><div> </div><div>Please ignore the Comment Due date. The OGC OWS Context Standards Working Group is happy to receive comments on this candidate standard at any time.</div><div> </div><div>Regards</div><div> </div><div>Carl Reed, PhD</div><div>CTO and Executive Director Standards Program</div><div>Open Geospatial Consortium</div><div><a href="http://www.opengeospatial.org">www.opengeospatial.org</a></div><div><br></div><div>The OGC: Making Location Count!</div><div><br></div><div>---------------------</div><div><br></div><div>This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies.</div><div><br></div><div>"The important thing is not to stop questioning." -- Albert Einstein </div><div>"Security is mostly a superstition. It does not exist in nature. Life is either a daring adventure or nothing." -- Helen Keller</div><div>_______________________________________________</div><div>Standards mailing list</div><div><a href="mailto:Standards@lists.osgeo.org">Standards@lists.osgeo.org</a></div><div><a href="http://lists.osgeo.org/mailman/listinfo/standards">http://lists.osgeo.org/mailman/listinfo/standards</a></div></div></blockquote></div></blockquote><div><br></div><div>_______________________________________________</div><div>Standards mailing list</div><div><a href="mailto:Standards@lists.osgeo.org">Standards@lists.osgeo.org</a></div><div><a href="http://lists.osgeo.org/mailman/listinfo/standards">http://lists.osgeo.org/mailman/listinfo/standards</a></div></div></blockquote></div></div></span>
                 
                 
                 
                 
                </blockquote>
                 
                <div>
                    <br>
                </div>