<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Verdana;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
h2
{mso-style-priority:9;
mso-style-link:"Heading 2 Char";
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:18.0pt;
font-family:"Times New Roman","serif";
font-weight:bold;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle17
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.Heading2Char
{mso-style-name:"Heading 2 Char";
mso-style-priority:9;
mso-style-link:"Heading 2";
font-weight:bold;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
{page:Section1;}
/* List Definitions */
@list l0
{mso-list-id:250234755;
mso-list-template-ids:1409814444;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1
{mso-list-id:983851504;
mso-list-template-ids:440666620;}
@list l1:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-US link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Hi,<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Here is the proposal part of the RFC with my comments to show my
concerns.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b><span
style='font-size:18.0pt'>Proposed Solution<a
href="http://trac.osgeo.org/fdo/wiki/FDORfc43#ProposedSolution"
title="Link to this section"> ¶</a><o:p></o:p></span></b></p>
<ul type=disc>
<li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
mso-list:l0 level1 lfo1'>Providers which don't support multiple schemas,
should report the parent folder name, all their content lives in that
single schema ( ie was default). <o:p></o:p></li>
</ul>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
style='color:#1F497D'>[OH] Given that we deal with file and database providers,
if we want a general convention when a schema name is not available, I would
prefer to call it something like “Default”. For providers that
handle a directory of files, I guess I wouldn’t be too adverse to using
the directory name.<o:p></o:p></span></p>
<ul type=disc>
<li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
mso-list:l0 level1 lfo1'>Providers which have native schemas with multiple
real schemas, should represent those available schemas to <a
href="http://trac.osgeo.org/fdo/wiki/GetSchemas">GetSchemas?</a> unless
over-ridden in the connection string or by custom mappings. <o:p></o:p></li>
</ul>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
style='color:#1F497D'>[OH] OK.<o:p></o:p></span></p>
<ul type=disc>
<li class=MsoNormal style='color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:
auto;mso-list:l0 level1 lfo1'>The tables in the user schema or single
folder are exposed via an empty schema (default). <o:p></o:p></li>
</ul>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
style='color:#1F497D'>[OH] I would rather avoid empty schema names and use
something like “Default”.<o:p></o:p></span></p>
<ul type=disc>
<li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
mso-list:l0 level1 lfo1'>Class names for databases are normally tablename,
unless qualified which then has ~COLUMN_NAME appended. (if the are
multiple geometries, FDO requires to know which one is the identifier) <o:p></o:p></li>
</ul>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
style='color:#1F497D'>[OH] I agree with class names for databases are normally derived
from table name (or view name), but I don’t want to require the
~COLUMN_NAME convention or require that a table with multiple geometries must
be mapped to multiple FDO classes. Providers may choose to do it that way or
providers may choose to map that to a single FDO class with multiple
geometries.<o:p></o:p></span></p>
<ul type=disc>
<li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
mso-list:l0 level1 lfo1'>Class names for file based providers is based on
their file name as current <o:p></o:p></li>
</ul>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
style='color:#1F497D'>[OH] OK, unless overridden by custom mappings as per your
second bullet.<o:p></o:p></span></p>
<ul type=disc>
<li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
mso-list:l0 level1 lfo1'>Therefore, The empty schema
":watercourses" could be also just "watercourses" <o:p></o:p></li>
</ul>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
style='color:#1F497D'>[OH] I prefer “Default:watercourses”.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Thanks,<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Orest.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>
<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
fdo-internals-bounces@lists.osgeo.org
[mailto:fdo-internals-bounces@lists.osgeo.org] <b>On Behalf Of </b>Orest
Halustchak<br>
<b>Sent:</b> Friday, October 30, 2009 9:20 AM<br>
<b>To:</b> FDO Internals Mail List<br>
<b>Subject:</b> RE: [fdo-internals] RE: [mapguide-internals] FDO RFC 43 -
Standard FDO Class Naming Conventions<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Hi Zac,<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Regarding separate FDO datastores within an Oracle instance,
I’m saying that a way to model that in Oracle is to create a new Oracle
user for each FDO datastore and then all the tables that I create for the
classes within that FDO datastore are all owned by the same Oracle user. So,
all the tables representing classes of a single FDO datastore are together.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>In your RFC, you said correctly that “…</span><span
lang=EN style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:black'>an
RDBMS schema might be composed of multiple logical schemas</span><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>”
where for Oracle, the “RDBMS schema” (same as Oracle user/owner)
called CityOfNewYork contains multiple logical FDO schemas of LandBase, Water,
and Gas. In this case, there is no need for metadata to identify the FDO
datastore contents, but metadata would be used to identify FDO schemas. Now, if
I connect to a datastore in Oracle and there is no further information about
FDO schemas, then we can use a default schema name such as
“Default”. I think I’d rather use “Default” than
having a blank name, which is one of the options that you mentioned in your RFC
and I wouldn’t have a problem in standardizing on “Default”.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Thanks,<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Orest.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>
<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
fdo-internals-bounces@lists.osgeo.org
[mailto:fdo-internals-bounces@lists.osgeo.org] <b>On Behalf Of </b>Zac Spitzer<br>
<b>Sent:</b> Thursday, October 29, 2009 8:10 PM<br>
<b>To:</b> FDO Internals Mail List<br>
<b>Subject:</b> Re: [fdo-internals] RE: [mapguide-internals] FDO RFC 43 -
Standard FDO Class Naming Conventions<o:p></o:p></span></p>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal style='margin-bottom:12.0pt'>Hi Orest,<br>
<br>
comments in line<o:p></o:p></p>
<div>
<p class=MsoNormal>On Fri, Oct 30, 2009 at 12:20 AM, Orest Halustchak <<a
href="mailto:orest.halustchak@autodesk.com">orest.halustchak@autodesk.com</a>>
wrote:<o:p></o:p></p>
<p class=MsoNormal>Hi Haris,<br>
<br>
Yes, datastore is identified at the connection. So, I probably shouldn't have
used the term "qualifier" for datastore, but maybe grouping
mechanism. Datastore contains schemas, which contain classes. You connect to
the datastore and then have access to the schemas and classes within that
datastore.<br>
<br>
>From the FDO developers guide, datastore is defined this way: "A data
store is a repository of an integrated set of objects. The objects in a data
store are modeled either by classes or feature classes defined within one or
more schemas."<br>
<br>
For the SQL Server case, a SQL Server database matches well with FDO datastore.
Tables within an SQL Server database are qualified by a schema name. The
default is "dbo", but you can define your own. Thus, we can match SQL
Server schema with FDO schema and SQL Server table with FDO class. So, in my
example, CityOfNewYork and CityOfAlbany can be captured as SQL Server databases
and that's how the SQL Server Spatial provider handles this. PostGIS also has a
similar physical structure, although the FDO PostGIS provider currently does
not take advantage of it and I think that's a bug.<br>
<br>
For the Oracle case, how do you capture separate FDO datastores within an
Oracle instance? The main grouping mechanism within an Oracle instance is an
Oracle owner (Oracle confuses things by using terms 'owner', 'user', and
'schema' for almost the same thing). So, if we use that grouping mechanism for
FDO datastore (else how do we handle multiple datastores within an Oracle
instance) and we map FDO classes to Oracle tables at the bottom end, then we
are missing a way to represent FDO schemas unless we add some additional
metadata to track that mapping. Without that mapping present, then we can
default to only a single FDO schema per datastore. An issue with using Oracle
schema for FDO schema is how would you distinguish between
CityOfNewYork.LandBase from CityOfAlbany.LandBase?<o:p></o:p></p>
<div>
<p class=MsoNormal><br>
can you elaborate on "separate FDO datastores within an Oracle
instance"<br>
<br>
I'm only familiar with a single oracle instance having (users/schemas/owners),<br>
are you referring to datastores via meta data? <br>
<br>
CityOfNewYork.LandBase from CityOfAlbany.LandBase would be seperate schema's<br>
and the unqualified LandBase would only refer to the Default Schema ie the
connected user?<br>
<br>
z<br>
<o:p></o:p></p>
</div>
<blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;
margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'>
<div>
<p class=MsoNormal><br>
Thanks,<br>
Orest.<br>
<br>
-----Original Message-----<br>
From: <a href="mailto:fdo-internals-bounces@lists.osgeo.org">fdo-internals-bounces@lists.osgeo.org</a>
[mailto:<a href="mailto:fdo-internals-bounces@lists.osgeo.org">fdo-internals-bounces@lists.osgeo.org</a>]
On Behalf Of Haris Kurtagic<o:p></o:p></p>
</div>
<div>
<div>
<p class=MsoNormal>Sent: Wednesday, October 28, 2009 4:20 PM<br>
To: 'FDO Internals Mail List'<br>
Subject: RE: [fdo-internals] RE: [mapguide-internals] FDO RFC 43 - Standard FDO
Class Naming Conventions<br>
<br>
Hi Orest,<br>
<br>
I maybe wrong, but would like to clarify it with you. Datastores are<br>
introduced basically with metadata tables describing fdo classes. So in that<br>
sense I understand that in one database we could have multiple datastores<br>
but trough metadata tables. With concept of what later called
"native"<br>
database classes there are no datastores ? That is my observation and same<br>
time question to you.<br>
Similar, regarding SQL server eventually we don't have database as level,<br>
because database is defined in connection string, right ?<br>
<br>
<br>
I agree about separate fdo classes for tables with multiple geometries, it<br>
would be nicer to have one class with multiple geometries.<br>
But, I think some APIs and even FDO based applications are making assumption<br>
about that one geometry is "main geometry".<br>
There is no way that provider could construct FDO class from such table, to<br>
know what is main geometry (without metadata).<br>
<br>
Haris<br>
<br>
-----Original Message-----<br>
From: <a href="mailto:fdo-internals-bounces@lists.osgeo.org">fdo-internals-bounces@lists.osgeo.org</a><br>
[mailto:<a href="mailto:fdo-internals-bounces@lists.osgeo.org">fdo-internals-bounces@lists.osgeo.org</a>]
On Behalf Of Orest Halustchak<br>
Sent: Wednesday, October 28, 2009 1:57 PM<br>
To: FDO Internals Mail List<br>
Subject: RE: [fdo-internals] RE: [mapguide-internals] FDO RFC 43 - Standard<br>
FDO Class Naming Conventions<br>
<br>
Hi,<br>
<br>
Note that there is another qualifier that should be taken into account in<br>
these discussions and that is the datastore name. There are really three<br>
levels of qualification: datastore name, schema name, class name. So, cases<br>
where it is suggested to use the file name as the schema name, if the file<br>
name is already used for the datastore name, it doesn't have to be used<br>
again for the schema name.<br>
<br>
An issue with rdbms is that some such as SQL Server include the three levels<br>
of database, schema, and table. Others such as Oracle do not. So in the<br>
Oracle case if we map the datastore name to the Oracle user/schema, then we<br>
should not also use Oracle user/schema for FDO schema.<br>
<br>
Consider this example.<br>
FDO Datastore = CityOfNewYork<br>
FDO Schema = LandBase<br>
Class = Parcel<br>
Class = Road<br>
FDO Schema = Water<br>
Class = Pipe<br>
Class = Valve<br>
FDO Schema = Gas<br>
Class = Pipe<br>
<br>
FDO Datastore = CityOfAlbany<br>
Same schemas and classes<br>
<br>
We don't want to mix up the parcels from CityOfNewYork with the parcles from<br>
CityOfAlbany, those should be in separate tables. Having the Oracle schema<br>
name as LandBase, Water, and Gas doesn't handle this.<br>
<br>
Also, about the ~ColumnName convention being used for geometry columns, note<br>
that FDO does allow more than one geometry column per class with one flagged<br>
as the main geometry. I wouldn't want to require that these have to be<br>
exposed as separate feature classes.<br>
<br>
Thanks,<br>
Orest.<br>
<br>
-----Original Message-----<br>
From: <a href="mailto:fdo-internals-bounces@lists.osgeo.org">fdo-internals-bounces@lists.osgeo.org</a><br>
[mailto:<a href="mailto:fdo-internals-bounces@lists.osgeo.org">fdo-internals-bounces@lists.osgeo.org</a>]
On Behalf Of Haris Kurtagic<br>
Sent: Wednesday, October 28, 2009 6:07 AM<br>
To: 'FDO Internals Mail List'<br>
Subject: [fdo-internals] RE: [mapguide-internals] FDO RFC 43 - Standard FDO<br>
Class Naming Conventions<br>
<br>
there is another important case which is not covered in RFC.<br>
Same table name in multiple schemas. Also, how to not mess up when users<br>
logs using different credentials.<br>
<br>
One way to solve that could be to always use rdbms schema name as fdo schema<br>
name.<br>
<br>
I believe it is absolutely necessary that application using FDO to access<br>
rdbms can be sure exactly which table and column it is accessing.<br>
Because what FDO provider sees when connects to rdbms can change regarding<br>
which credentials are used to connect to rdbms. That menas that on same<br>
database it can see only one table, or two tables (same name) in two schemas<br>
or even one or more geometry columns in table.<br>
<br>
I am not keen on current naming in King.Oracle with this ~ sign, but I am<br>
very pleased that when using King.Oracle and FDO class trough it, I know<br>
every time exactly which Oracle schema, table and column I am hitting.<br>
<br>
<br>
<br>
<br>
Just when wanted to finish something else from RFC:<br>
"Class names for databases are normally tablename, unless qualified which<br>
then has ~COLUMN_NAME appended. (if the are multiple geometries, FDO<br>
requires to know which one is the identifier)"<br>
<br>
In King.Oracle ~COLUMN_NAME is appened to make sure resulting name would be<br>
unique. Which actuall oracle column is used is not parsed from name of class<br>
but it is kept inside provider. ~COLUMN_NAME could be anything.<br>
<br>
<br>
Haris<br>
<br>
-----Original Message-----<br>
From: <a href="mailto:mapguide-internals-bounces@lists.osgeo.org">mapguide-internals-bounces@lists.osgeo.org</a><br>
[mailto:<a href="mailto:mapguide-internals-bounces@lists.osgeo.org">mapguide-internals-bounces@lists.osgeo.org</a>]
On Behalf Of Zac Spitzer<br>
Sent: Wednesday, October 28, 2009 9:45 AM<br>
To: FDO Internals Mail List; MapGuide Internals Mail List<br>
Subject: [mapguide-internals] FDO RFC 43 - Standard FDO Class Naming<br>
Conventions<br>
<br>
I have posted RFC 43 for review<br>
<br>
<a href="http://trac.osgeo.org/fdo/wiki/FDORfc43" target="_blank">http://trac.osgeo.org/fdo/wiki/FDORfc43</a><br>
<br>
--<br>
Zac Spitzer -<br>
<a href="http://zacster.blogspot.com" target="_blank">http://zacster.blogspot.com</a><br>
+61 405 847 168<br>
_______________________________________________<br>
mapguide-internals mailing list<br>
<a href="mailto:mapguide-internals@lists.osgeo.org">mapguide-internals@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/mapguide-internals"
target="_blank">http://lists.osgeo.org/mailman/listinfo/mapguide-internals</a><br>
<br>
_______________________________________________<br>
fdo-internals mailing list<br>
<a href="mailto:fdo-internals@lists.osgeo.org">fdo-internals@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/fdo-internals" target="_blank">http://lists.osgeo.org/mailman/listinfo/fdo-internals</a><br>
_______________________________________________<br>
fdo-internals mailing list<br>
<a href="mailto:fdo-internals@lists.osgeo.org">fdo-internals@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/fdo-internals" target="_blank">http://lists.osgeo.org/mailman/listinfo/fdo-internals</a><br>
<br>
_______________________________________________<br>
fdo-internals mailing list<br>
<a href="mailto:fdo-internals@lists.osgeo.org">fdo-internals@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/fdo-internals" target="_blank">http://lists.osgeo.org/mailman/listinfo/fdo-internals</a><br>
_______________________________________________<br>
fdo-internals mailing list<br>
<a href="mailto:fdo-internals@lists.osgeo.org">fdo-internals@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/fdo-internals" target="_blank">http://lists.osgeo.org/mailman/listinfo/fdo-internals</a><o:p></o:p></p>
</div>
</div>
</blockquote>
</div>
<p class=MsoNormal><br>
<br clear=all>
<br>
-- <br>
Zac Spitzer -<br>
<a href="http://zacster.blogspot.com">http://zacster.blogspot.com</a><br>
+61 405 847 168<o:p></o:p></p>
</div>
</body>
</html>