Re: [Ecrit] Profiles (was: Consensus Call) - namespaces

[Henning Schulzrinne <hgs at cs.columbia.edu>]

There seem to be several different topics here, so I'll split my  
response.

On Apr 24, 2007, at 2:07 PM, Andrew Newton wrote:

> On Apr 24, 2007, at 12:08 PM, Henning Schulzrinne wrote:
> > - The core problem is that the profile notion makes it impossible  
> > to upgrade any LCP without upgrading all clients since a client  
> > (LCP querier and LoST seeker) would have to recognize the  
> > <location-info> format to insert the right profile information,  
> > even though the client doesn't touch the <location-info> and  
> > simply copies it from LCP to LoST verbatim.  As far as I know,  
> > HELD provides no way to request a specific LoST profile, either.
>
> Actually, this introduces more problems as the server has to guess  
> at the meaning of the data.  Take for instance a future location  
> profile based on RFC 3825... and you find this in draft-ietf- 
> geopriv-lo-profile-06:
>
> <gml:Point srsName="urn:ogc:def:crs:EPSG::4326"
>   <gml:pos>-43.5723 153.21760</gml:pos>
> </gml:Point>
> <cl:civicAddress>
>   <cl:FLR>2</cl:FLR>
> </cl:civicAddress>
>
> Just looking at the GML XML namespace is not enough to know that  
> the format is 3825.

The receiver doesn't care that the format is derived from RFC 3825.  
The namespace declaration (which you elided in your example)

  xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"

identifies the schema, so the receiver can easily tell whether it  
should ignore or handle the XML tags or not (or decide that it needs  
to give up instead). Thus, it can tell what meaning FLR has and  
whether it knows anything about that particular XML tag.

Henning



_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit