The OGC requests comments on the OWS Context Conceptual Model and ATOM Extension candidate standards

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

The OGC requests comments on the OWS Context Conceptual Model and ATOM Extension candidate standards

Carl Reed
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.
 
The announcement is here:
 
 
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.
 
Regards
 
Carl Reed, PhD
CTO and Executive Director Standards Program
Open Geospatial Consortium
www.opengeospatial.org

The OGC: Making Location Count!

---------------------

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.

"The important thing is not to stop questioning." -- Albert Einstein
"Security is mostly a superstition. It does not exist in nature. Life is either a daring adventure or nothing." -- Helen Keller

_______________________________________________
Standards mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/standards
Reply | Threaded
Open this post in threaded view
|

Re: The OGC requests comments on the OWS Context Conceptual Model and ATOM Extension candidate standards

jody.garnett
Last time I looked at this one with Jim … I hated it (even though he was keen on how ATOM had been used).
For me It was not providing enough context for a client to make its own request.

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).

Tracing through your links I arrive at some word docs, don't suppose you can format shift those to PDF or something more portable.

-- 
Jody Garnett

On Tuesday, 19 February 2013 at 3:39 AM, Carl Reed wrote:

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.
 
The announcement is here:
 
 
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.
 
Regards
 
Carl Reed, PhD
CTO and Executive Director Standards Program
Open Geospatial Consortium
www.opengeospatial.org

The OGC: Making Location Count!

---------------------

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.

"The important thing is not to stop questioning." -- Albert Einstein
"Security is mostly a superstition. It does not exist in nature. Life is either a daring adventure or nothing." -- Helen Keller
_______________________________________________
Standards mailing list


_______________________________________________
Standards mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/standards
Reply | Threaded
Open this post in threaded view
|

Re: The OGC requests comments on the OWS Context Conceptual Model and ATOM Extension candidate standards

jody.garnett
Quick feedback:

Conceptual Model

So much better than last time I looked. GetCapabilities is now listed allowing client to perform version negotiation and figure out what it can support, indeed that is listed as a "Key Requirement" this time out.

A few of the sections later on could benefit from some Q&A for consistency … 

GeoTIFF is marked as "This class describes the extension to the OWS Context Core which supports in-line or referenced offerings. ; this can include referencing local files or into databases."

However the details only provide "content" that is a "Local reference to a File" - this does not on the face of it indicate support for "in-line" GeoTIFF provided as part of the context document.

I am also looking for a vendor extension section, so that the lowly shapefile can be supported (as this is still a primary use case for desktop apps).

ATOM Encoding

I eventually skipped to the examples, I like the smooth ramp up between simply listing operations (HTTP GET GetCapabilities, GetXXXX), through to allowing HTTP Post, through to caching the results at the time the context was created. This would allow an application to display what was intended (say what a decision was based on) and then "refresh" it to reflect the current operating picture.

-- 
Jody Garnett

On Tuesday, 19 February 2013 at 10:41 AM, Jody Garnett wrote:

Last time I looked at this one with Jim … I hated it (even though he was keen on how ATOM had been used).
For me It was not providing enough context for a client to make its own request.

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).

Tracing through your links I arrive at some word docs, don't suppose you can format shift those to PDF or something more portable.

-- 
Jody Garnett

On Tuesday, 19 February 2013 at 3:39 AM, Carl Reed wrote:

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.
 
The announcement is here:
 
 
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.
 
Regards
 
Carl Reed, PhD
CTO and Executive Director Standards Program
Open Geospatial Consortium
www.opengeospatial.org

The OGC: Making Location Count!

---------------------

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.

"The important thing is not to stop questioning." -- Albert Einstein
"Security is mostly a superstition. It does not exist in nature. Life is either a daring adventure or nothing." -- Helen Keller
_______________________________________________
Standards mailing list



_______________________________________________
Standards mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/standards
Reply | Threaded
Open this post in threaded view
|

Re: The OGC requests comments on the OWS Context Conceptual Model and ATOM Extension candidate standards

jody.garnett
In reply to this post by jody.garnett
So back to my origional feedback to Jim.

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.

If you swap perspective to that of an implementor you are left with … a gap of understanding.

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.

This standard is lazy on the part of the standards body, and hostile to client authors.

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.

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.

So kudos on the reuse of definitions, missed the target audience when considering implementors (you have asked for too much work).
-- 
Jody Garnett

On Tuesday, 19 February 2013 at 10:41 AM, Jody Garnett wrote:

Last time I looked at this one with Jim … I hated it (even though he was keen on how ATOM had been used).
For me It was not providing enough context for a client to make its own request.

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).

Tracing through your links I arrive at some word docs, don't suppose you can format shift those to PDF or something more portable.

-- 
Jody Garnett

On Tuesday, 19 February 2013 at 3:39 AM, Carl Reed wrote:

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.
 
The announcement is here:
 
 
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.
 
Regards
 
Carl Reed, PhD
CTO and Executive Director Standards Program
Open Geospatial Consortium
www.opengeospatial.org

The OGC: Making Location Count!

---------------------

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.

"The important thing is not to stop questioning." -- Albert Einstein
"Security is mostly a superstition. It does not exist in nature. Life is either a daring adventure or nothing." -- Helen Keller
_______________________________________________
Standards mailing list



_______________________________________________
Standards mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/standards
Reply | Threaded
Open this post in threaded view
|

Re: The OGC requests comments on the OWS Context Conceptual Model and ATOM Extension candidate standards

Carl Reed
In reply to this post by jody.garnett
Jody -
 
I can provide PDFs.
 
Cheers
 
Carl
 
 
Sent: Monday, February 18, 2013 4:41 PM
Subject: Re: [OSGeo-Standards] The OGC requests comments on the OWS Context Conceptual Model and ATOM Extension candidate standards
 
Last time I looked at this one with Jim … I hated it (even though he was keen on how ATOM had been used).
For me It was not providing enough context for a client to make its own request.
 
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).
 
Tracing through your links I arrive at some word docs, don't suppose you can format shift those to PDF or something more portable.
 
--
Jody Garnett
 

On Tuesday, 19 February 2013 at 3:39 AM, Carl Reed wrote:

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.
 
The announcement is here:
 
 
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.
 
Regards
 
Carl Reed, PhD
CTO and Executive Director Standards Program
Open Geospatial Consortium
www.opengeospatial.org

The OGC: Making Location Count!

---------------------

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.

"The important thing is not to stop questioning." -- Albert Einstein
"Security is mostly a superstition. It does not exist in nature. Life is either a daring adventure or nothing." -- Helen Keller
_______________________________________________
Standards mailing list
 

_______________________________________________
Standards mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/standards
Reply | Threaded
Open this post in threaded view
|

Re: The OGC requests comments on the OWS Context Conceptual Model and ATOM Extension candidate standards

Carl Reed
In reply to this post by jody.garnett
Jody -
 
OWS Context Conceptual Model as a PDF. More later.
 
Cheers
 
Carl
 
 
Sent: Monday, February 18, 2013 6:59 PM
Subject: Re: [OSGeo-Standards] The OGC requests comments on the OWS Context Conceptual Model and ATOM Extension candidate standards
 
So back to my origional feedback to Jim.
 
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.
 
If you swap perspective to that of an implementor you are left with … a gap of understanding.
 
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.
 
This standard is lazy on the part of the standards body, and hostile to client authors.
 
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.
 
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.
 
So kudos on the reuse of definitions, missed the target audience when considering implementors (you have asked for too much work).
--
Jody Garnett
 

On Tuesday, 19 February 2013 at 10:41 AM, Jody Garnett wrote:

Last time I looked at this one with Jim … I hated it (even though he was keen on how ATOM had been used).
For me It was not providing enough context for a client to make its own request.
 
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).
 
Tracing through your links I arrive at some word docs, don't suppose you can format shift those to PDF or something more portable.
 
--
Jody Garnett
 

On Tuesday, 19 February 2013 at 3:39 AM, Carl Reed wrote:

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.
 
The announcement is here:
 
 
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.
 
Regards
 
Carl Reed, PhD
CTO and Executive Director Standards Program
Open Geospatial Consortium
www.opengeospatial.org

The OGC: Making Location Count!

---------------------

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.

"The important thing is not to stop questioning." -- Albert Einstein
"Security is mostly a superstition. It does not exist in nature. Life is either a daring adventure or nothing." -- Helen Keller
_______________________________________________
Standards mailing list
 
 

_______________________________________________
Standards mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/standards

12-080_OWS_Context_Conceptual_Model.pdf (1M) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: The OGC requests comments on the OWS Context Conceptual Model and ATOM Extension candidate standards

Raj Singh-3
In reply to this post by jody.garnett
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 ;)

---
Raj
The OGC: Making location count.
http://www.opengeospatial.org/ogc/organization/staff/rsingh


On Feb 18, at 8:59 PM, Jody Garnett <[hidden email]> wrote:

> So back to my origional feedback to Jim.
>
> 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.
>
> If you swap perspective to that of an implementor you are left with … a gap of understanding.
>
> 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.
>
> This standard is lazy on the part of the standards body, and hostile to client authors.
>
> 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.
>
> 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.
>
> So kudos on the reuse of definitions, missed the target audience when considering implementors (you have asked for too much work).
> --
> Jody Garnett
>
> On Tuesday, 19 February 2013 at 10:41 AM, Jody Garnett wrote:
>
>> Last time I looked at this one with Jim … I hated it (even though he was keen on how ATOM had been used).
>> For me It was not providing enough context for a client to make its own request.
>>
>> 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).
>>
>> Tracing through your links I arrive at some word docs, don't suppose you can format shift those to PDF or something more portable.
>>
>> --
>> Jody Garnett
>>
>> On Tuesday, 19 February 2013 at 3:39 AM, Carl Reed wrote:
>>
>>> 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.
>>>  
>>> The announcement is here:
>>>  
>>> http://www.opengeospatial.org/node/1765
>>>  
>>> 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.
>>>  
>>> Regards
>>>  
>>> Carl Reed, PhD
>>> CTO and Executive Director Standards Program
>>> Open Geospatial Consortium
>>> www.opengeospatial.org
>>>
>>> The OGC: Making Location Count!
>>>
>>> ---------------------
>>>
>>> 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.
>>>
>>> "The important thing is not to stop questioning." -- Albert Einstein
>>> "Security is mostly a superstition. It does not exist in nature. Life is either a daring adventure or nothing." -- Helen Keller
>>> _______________________________________________
>>> Standards mailing list
>>> [hidden email]
>>> http://lists.osgeo.org/mailman/listinfo/standards
>>
>
> _______________________________________________
> Standards mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/standards

_______________________________________________
Standards mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/standards
Reply | Threaded
Open this post in threaded view
|

Re: The OGC requests comments on the OWS Context Conceptual Model and ATOM Extension candidate standards

jody.garnett
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

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).

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 <id> element to hold the layer name, and go through the remaining standards and perform a similar "mapping".

What we need to facilitate discussion is a working example:

<feed xmlns=“http://www.w3.org/2005/Atom”
   xmlns:owc=“http://www.opengis.net/owc/1.0”
   xml:lang=“en”>
   ...
   <entry>
     <id>http://someserver.com/#base</id>
     <title>Base World Map</title>
     ....
     <owc:offering code=“http://www.opengis.net/spec/owc/1.0/req/atom/wms”>
       <owc:operation
         method=“GET”
         code=“GetCapabilities”
         href=“http://www.someserver.com/wrs.cgi?
             REQUEST=GetCapabilities&amp;
             SERVICE=WMS &amp;
             VERSION=1.1.1”/>
       <ows:operation
         method="GET"
         code="GetMap"
         href="http://www.someserver.com/wrs.cgi?
             REQUEST=GetMap&amp;
             SERVICE=WMS&amp;
             VERSION=1.1.1&amp;
             layers=topp%3Aabse&amp;
             styles=&amp;
             srs=EPSG%3A4326&amp;
             bbox=-145.15104058007,21.731919794922,
                  -57.154894212888,58.961058642578&amp;
             width=780&amp;
             height=330&amp;
             format=image%2Fpng"/>
     </owc:offering>
   <entry>

-- 
Jody Garnett

On Wednesday, 20 February 2013 at 9:01 AM, Raj Singh wrote:

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 ;)

---
Raj
The OGC: Making location count.


On Feb 18, at 8:59 PM, Jody Garnett <[hidden email]> wrote:

So back to my origional feedback to Jim.

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.

If you swap perspective to that of an implementor you are left with … a gap of understanding.

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.

This standard is lazy on the part of the standards body, and hostile to client authors.

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.

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.

So kudos on the reuse of definitions, missed the target audience when considering implementors (you have asked for too much work).
--
Jody Garnett

On Tuesday, 19 February 2013 at 10:41 AM, Jody Garnett wrote:

Last time I looked at this one with Jim … I hated it (even though he was keen on how ATOM had been used).
For me It was not providing enough context for a client to make its own request.

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).

Tracing through your links I arrive at some word docs, don't suppose you can format shift those to PDF or something more portable.

--
Jody Garnett

On Tuesday, 19 February 2013 at 3:39 AM, Carl Reed wrote:

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.
The announcement is here:
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.
Regards
Carl Reed, PhD
CTO and Executive Director Standards Program
Open Geospatial Consortium

The OGC: Making Location Count!

---------------------

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.

"The important thing is not to stop questioning." -- Albert Einstein
"Security is mostly a superstition. It does not exist in nature. Life is either a daring adventure or nothing." -- Helen Keller
_______________________________________________
Standards mailing list

_______________________________________________
Standards mailing list


_______________________________________________
Standards mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/standards
Reply | Threaded
Open this post in threaded view
|

Re: The OGC requests comments on the OWS Context Conceptual Model and ATOM Extension candidate standards

Raj Singh-3
Ah I think I get it now. So you're saying that now all the parameters of the GetMap request have to be pulled out of the href property of <ows:operation> instead of each parameter being separate properties of <ows:operation>. Is that correct?

If so, then that's a decision we went around and around on for a long time. The only concrete reason to do it this way (that I can remember) was that even a client app that wasn't very smart about Geo "stuff" could still have a good chance of reproducing the original map because all they have to do is resolve the hrefs and overlay them on top of each other. In a more parameterized format, the client would need to know how to put together a WMS request to get anything.

However, I don't think anyone was completely against the old way of doing things, and getting feedback on issues like this is what public comment periods are for. Anyone else have a preference/comment?

---
Raj
The OGC: Making location count.
http://www.opengeospatial.org/ogc/organization/staff/rsingh


On Feb 19, at 7:20 PM, Jody Garnett <[hidden email]> wrote:

> 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
>
> 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).
>
> 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 <id> element to hold the layer name, and go through the remaining standards and perform a similar "mapping".
>
> What we need to facilitate discussion is a working example:
>
> <feed xmlns=“http://www.w3.org/2005/Atom”
>    xmlns:owc=“http://www.opengis.net/owc/1.0”
>    xml:lang=“en”>
>    ...
>    <entry>
>      <id>http://someserver.com/#base</id>
>      <title>Base World Map</title>
>      ....
>      <owc:offering code=“http://www.opengis.net/spec/owc/1.0/req/atom/wms”>
>        <owc:operation
>          method=“GET”
>          code=“GetCapabilities”
>          href=“http://www.someserver.com/wrs.cgi?
>              REQUEST=GetCapabilities&amp;
>              SERVICE=WMS &amp;
>              VERSION=1.1.1”/>
>        <ows:operation
>          method="GET"
>          code="GetMap"
>          href="http://www.someserver.com/wrs.cgi?
>              REQUEST=GetMap&amp;
>              SERVICE=WMS&amp;
>              VERSION=1.1.1&amp;
>              layers=topp%3Aabse&amp;
>              styles=&amp;
>              srs=EPSG%3A4326&amp;
>              bbox=-145.15104058007,21.731919794922,
>                   -57.154894212888,58.961058642578&amp;
>              width=780&amp;
>              height=330&amp;
>              format=image%2Fpng"/>
>      </owc:offering>
>    <entry>
>
> --
> Jody Garnett
>
> On Wednesday, 20 February 2013 at 9:01 AM, Raj Singh wrote:
>
>> 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 ;)
>>
>> ---
>> Raj
>> The OGC: Making location count.
>> http://www.opengeospatial.org/ogc/organization/staff/rsingh
>>
>>
>> On Feb 18, at 8:59 PM, Jody Garnett <[hidden email]> wrote:
>>
>>> So back to my origional feedback to Jim.
>>>
>>> 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.
>>>
>>> If you swap perspective to that of an implementor you are left with … a gap of understanding.
>>>
>>> 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.
>>>
>>> This standard is lazy on the part of the standards body, and hostile to client authors.
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> So kudos on the reuse of definitions, missed the target audience when considering implementors (you have asked for too much work).
>>> --
>>> Jody Garnett
>>>
>>> On Tuesday, 19 February 2013 at 10:41 AM, Jody Garnett wrote:
>>>
>>>> Last time I looked at this one with Jim … I hated it (even though he was keen on how ATOM had been used).
>>>> For me It was not providing enough context for a client to make its own request.
>>>>
>>>> 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).
>>>>
>>>> Tracing through your links I arrive at some word docs, don't suppose you can format shift those to PDF or something more portable.
>>>>
>>>> --
>>>> Jody Garnett
>>>>
>>>> On Tuesday, 19 February 2013 at 3:39 AM, Carl Reed wrote:
>>>>
>>>>> 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.
>>>>> The announcement is here:
>>>>> http://www.opengeospatial.org/node/1765
>>>>> 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.
>>>>> Regards
>>>>> Carl Reed, PhD
>>>>> CTO and Executive Director Standards Program
>>>>> Open Geospatial Consortium
>>>>> www.opengeospatial.org
>>>>>
>>>>> The OGC: Making Location Count!
>>>>>
>>>>> ---------------------
>>>>>
>>>>> 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.
>>>>>
>>>>> "The important thing is not to stop questioning." -- Albert Einstein
>>>>> "Security is mostly a superstition. It does not exist in nature. Life is either a daring adventure or nothing." -- Helen Keller
>>>>> _______________________________________________
>>>>> Standards mailing list
>>>>> [hidden email]
>>>>> http://lists.osgeo.org/mailman/listinfo/standards
>>>
>>> _______________________________________________
>>> Standards mailing list
>>> [hidden email]
>>> http://lists.osgeo.org/mailman/listinfo/standards
>

_______________________________________________
Standards mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/standards
Reply | Threaded
Open this post in threaded view
|

Re: The OGC requests comments on the OWS Context Conceptual Model and ATOM Extension candidate standards

jody.garnett
We are getting much closer Raj. I read over your response a few time make sure I understand it. It would help if you could provide an example.

I was aiming to pull the information up to the <ows:entry> level, and yes I am starting from the base assumption that a client has to perform version negotiation and issue a new GetMap request to match their abilities (supported protocol) and environment (screen size and DPI).

I will think about it (entry or operation). It may be advantageous to list multiple <ows:operations> incase the information was available from several sources (an inline geotiff overview, a WMTS and a WMS for example).

Although my feedback was harsh, I am really keen on several improvements that have been made.

Having access to the GetCapabilities endpoint fills in a major gap. It allows me as a client to go to the original server and see what is available - perform version negotiation if required and determine what abilities of the server I can make use of as a client.  Previously this was an implicit assumption that a GetCapabilities would be available at the same end-point as the GetMap operation.

Idea: Only thing that could be better here is to allows (a) GetCapabilities to respond to a request for the capabilities of a single layer, and (b) inline that cut down Capabilities document. This would allow the context document to (in the best case) communicate the information required to issue a GetMap request.

Still explicitly listing the GetCapabilities endpoint is the big win here.

The final thing I need to figure out is how vendor extensions work, so that a reference to a local shapefile can be made. Still the main use case for sharing a map between applications.  By going with a specific GML entry, rather than feature, I do not have the option of just changing mime type and referencing a different file.

-- 
Jody Garnett

On Thursday, 21 February 2013 at 2:33 AM, Raj Singh wrote:

Ah I think I get it now. So you're saying that now all the parameters of the GetMap request have to be pulled out of the href property of <ows:operation> instead of each parameter being separate properties of <ows:operation>. Is that correct?

If so, then that's a decision we went around and around on for a long time. The only concrete reason to do it this way (that I can remember) was that even a client app that wasn't very smart about Geo "stuff" could still have a good chance of reproducing the original map because all they have to do is resolve the hrefs and overlay them on top of each other. In a more parameterized format, the client would need to know how to put together a WMS request to get anything.

However, I don't think anyone was completely against the old way of doing things, and getting feedback on issues like this is what public comment periods are for. Anyone else have a preference/comment?

---
Raj
The OGC: Making location count.


On Feb 19, at 7:20 PM, Jody Garnett <[hidden email]> wrote:

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

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).

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 <id> element to hold the layer name, and go through the remaining standards and perform a similar "mapping".

What we need to facilitate discussion is a working example:

<feed xmlns=“http://www.w3.org/2005/Atom
xml:lang=“en”>
...
<entry>
<title>Base World Map</title>
....
<owc:operation
method=“GET”
code=“GetCapabilities”
REQUEST=GetCapabilities&amp;
SERVICE=WMS &amp;
VERSION=1.1.1”/>
<ows:operation
method="GET"
code="GetMap"
REQUEST=GetMap&amp;
SERVICE=WMS&amp;
VERSION=1.1.1&amp;
layers=topp%3Aabse&amp;
styles=&amp;
srs=EPSG%3A4326&amp;
bbox=-145.15104058007,21.731919794922,
-57.154894212888,58.961058642578&amp;
width=780&amp;
height=330&amp;
format=image%2Fpng"/>
</owc:offering>
<entry>

--
Jody Garnett

On Wednesday, 20 February 2013 at 9:01 AM, Raj Singh wrote:

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 ;)

---
Raj
The OGC: Making location count.


On Feb 18, at 8:59 PM, Jody Garnett <[hidden email]> wrote:

So back to my origional feedback to Jim.

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.

If you swap perspective to that of an implementor you are left with … a gap of understanding.

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.

This standard is lazy on the part of the standards body, and hostile to client authors.

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.

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.

So kudos on the reuse of definitions, missed the target audience when considering implementors (you have asked for too much work).
--
Jody Garnett

On Tuesday, 19 February 2013 at 10:41 AM, Jody Garnett wrote:

Last time I looked at this one with Jim … I hated it (even though he was keen on how ATOM had been used).
For me It was not providing enough context for a client to make its own request.

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).

Tracing through your links I arrive at some word docs, don't suppose you can format shift those to PDF or something more portable.

--
Jody Garnett

On Tuesday, 19 February 2013 at 3:39 AM, Carl Reed wrote:

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.
The announcement is here:
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.
Regards
Carl Reed, PhD
CTO and Executive Director Standards Program
Open Geospatial Consortium

The OGC: Making Location Count!

---------------------

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.

"The important thing is not to stop questioning." -- Albert Einstein
"Security is mostly a superstition. It does not exist in nature. Life is either a daring adventure or nothing." -- Helen Keller
_______________________________________________
Standards mailing list

_______________________________________________
Standards mailing list


_______________________________________________
Standards mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/standards
Reply | Threaded
Open this post in threaded view
|

Re: The OGC requests comments on the OWS Context Conceptual Model and ATOM Extension candidate standards

Arnulf Christl-3
In reply to this post by Raj Singh-3
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/19/2013 02:01 PM, Raj Singh wrote:

> 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 ;)
>
> --- Raj The OGC: Making location count.
> http://www.opengeospatial.org/ogc/organization/staff/rsingh
>
>
> On Feb 18, at 8:59 PM, Jody Garnett <[hidden email]>
> wrote:
>
>> So back to my origional feedback to Jim.
>>
>> 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.
>>
>> If you swap perspective to that of an implementor you are left
>> with … a gap of understanding.
>>
>> 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.
>>
>> This standard is lazy on the part of the standards body, and
>> hostile to client authors.
>>
>> 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.
>>
>> 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.
>>
>> So kudos on the reuse of definitions, missed the target audience
>> when considering implementors (you have asked for too much work).
>>  -- Jody Garnett
>>
>> On Tuesday, 19 February 2013 at 10:41 AM, Jody Garnett wrote:
>>
>>> Last time I looked at this one with Jim … I hated it (even
>>> though he was keen on how ATOM had been used). For me It was
>>> not providing enough context for a client to make its own
>>> request.
>>>
>>> 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).
>>>
>>> Tracing through your links I arrive at some word docs, don't
>>> suppose you can format shift those to PDF or something more
>>> portable.

HTML is in the pipeline and way better than PDF. But will take some
time and also not sure whether it will happen for all the existing
documents (maybe with some help from the editors if still alive?).

>>> -- Jody Garnett
>>>
>>> On Tuesday, 19 February 2013 at 3:39 AM, Carl Reed wrote:
>>>
>>>> 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.
>>>>
>>>> The announcement is here:
>>>>
>>>> http://www.opengeospatial.org/node/1765
>>>>
>>>> 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.
>>>>
>>>> Regards
>>>>
>>>> Carl Reed, PhD CTO and Executive Director Standards Program
>>>> Open Geospatial Consortium www.opengeospatial.org
>>>>
>>>> The OGC: Making Location Count!
>>>>
>>>> ---------------------
>>>>
>>>> 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.
>>>>
>>>> "The important thing is not to stop questioning." -- Albert
>>>> Einstein "Security is mostly a superstition. It does not
>>>> exist in nature. Life is either a daring adventure or
>>>> nothing." -- Helen Keller
>>>> _______________________________________________ Standards
>>>> mailing list [hidden email]
>>>> http://lists.osgeo.org/mailman/listinfo/standards
>>>
>>
>> _______________________________________________ Standards
>> mailing list [hidden email]
>> http://lists.osgeo.org/mailman/listinfo/standards
>
> _______________________________________________ Standards mailing
> list [hidden email]
> http://lists.osgeo.org/mailman/listinfo/standards
>


- --
Arnulf Christl
http://metaspatial.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlElghEACgkQXmFKW+BJ1b0e0gCeM2jt2Rhn3cFcWtYc6fiAx3OQ
vwcAn1cHzzSuFZyChVeUqYlTEbUf88OW
=yRsr
-----END PGP SIGNATURE-----
_______________________________________________
Standards mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/standards