Subject: RE: [Geopriv] URI in civic-lo

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 9 Nov 2005 18:15:07 -0600

Hi Andrew,

Thank you for the speedy follow-up comments.
I guess that I can see 4 ways to easily address the problem here.

1) Provision your serving database in such a way that it takes care of
this for you. That is push it into the application space.

2) Include a specific "This is what this stuff means" URI into the civic
format. How to interpret what is at the end of the URI I think will be
problematic for the reasons that Ted described.

3) Extend the civic representation with your own application specific
parameters that enforce the XML constraints that you want through
schema. This is possible as the schema says:
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
At the bottom.

4) Create your own entirely new application specific location type and
include that in the location-info element of the PIDF-LO. This allows
you to enforce whatever constraints you want over any fields of your
choosing.

I am sure that people that other people may have other suggestions.
These are just the 4 that leap out at me.

Cheers
James

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Andrew Daviel
> Sent: Thursday, 10 November 2005 10:56 AM
> To: [email-masked]
> Subject: [Geopriv] URI in civic-lo
> 
> 
> I suggested adding an (optional) informational URI to
> PIDF-LO to describe elements added in
> draft-thomson-revised-civic-lo-01
> and was asked to provide examples and/or justification
> 
> IMO there's no point in creating a structured record for something
like
> civil location unless everyone agrees what the fields mean and what is
> valid content for those fields. Otherwise you might just as well use
> a free-text field, because you can't do computation on them. (Yes
there
> are many applications which can somehow extract location from
> free-text addresses; they work surprisingly well given a North
American
> grid-based urban address, where street numbers can be mapped into
> East or North distances. They don't do so well outside this space)
> 
> Thanks to Internet top-level domains we have a pretty good idea of
> what are acceptable values for a country field. And given
> the country, we have some idea of valid values for
state/province/county
> fields (though even within a country, there is some variation in
> e.g. abbreviation - W. York./West Yorkshire; Alberta/AB/Alta - which
may
> be readily understood by the Post Office but less so by software)
> 
> draft-thomson-revised-civic-lo introduces some distinctly local
> fields, such as Building, Room and Seat. The format of these cannot be
> guessed outside of the application, so it would be easy to generate
> syntactically correct PIDF records that are nevertheless useless
because
> they use the wrong field values.
> For instance, I maintain a network device database to answer the
question
> "where is 192.168.4.56 and who owns it?". To answer this, the value
for
> "building" must be taken from a list (the names are not written on the
> buildings, and a building I define as "MOB" may variously be referred
to
> as "the administration building", "the main office building", "the
office
> building" etc.)
> 
> 
> So I think there should be a mechanism provided within the PIDF
document
> to explain the fields and possibly enumerate allowed values.
> 
> Ideally, this would be a URI to a namespace that could be used to
> create or validate a PIDF record to this level of detail. I don't know
XML
> well enough to define this, but I would think that XML with
> inheritance could be used - the descriptor for the network database
> inherits an organization-wide descriptor for buildings, which in turn
> inherits a city or country-wide descriptor (Canada Post puts out a
text
> document describing how you are supposed to write street addresses..)
> etc.
> 
> Failing some kind of structured document, anything is better than
nothing,
> so a text document describing (to a human) the fields would help
> humans create or understand the PIDF records.
> 
> 
> It's all very well to push the problem off to the application layer,
but
> if there are multiple applications all hoping to use the same records,
> that will lead to chaos.
> 
> 
> Andrew Daviel
> Vancouver Webpages
> 
> 
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/geopriv

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: Andrew Daviel <[email-masked]>
Date: Wed, 09 Nov 2005 16:41:23 -0800 (PST)

> problematic for the reasons that Ted described.

If the XML can be extended in a well-defined way, it might still be nice
to have an optional text page for the benefit of any humans trying to
interpret things. But not so essential.

> <xs:any namespace="##other" processContents="lax" minOccurs="0"

OK, that sounds like what I was trying to say. Maybe a comment to say this
is possible/recommended ?
Not being that XML-savvy of course I'd like an example ...

Andrew Daviel
Vancouver Webpages