<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:x="urn:schemas-microsoft-com:office:excel" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:a="urn:schemas-microsoft-com:office:access" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema" xmlns:b="urn:schemas-microsoft-com:office:publisher" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:c="urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc="urn:schemas-microsoft-com:office:odc" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:q="http://schemas.xmlsoap.org/soap/envelope/" xmlns:D="DAV:" xmlns:x2="http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ois="http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir="http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsp="http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc="http://schemas.microsoft.com/data/udc" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sub="http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec="http://www.w3.org/2001/04/xmlenc#" xmlns:sp="http://schemas.microsoft.com/sharepoint/" xmlns:sps="http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:udcxf="http://schemas.microsoft.com/data/udc/xmlfile" xmlns:wf="http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:mver="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels="http://schemas.openxmlformats.org/package/2006/relationships" xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:Z="urn:schemas-microsoft-com:" xmlns:st="" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@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;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
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;}
span.EmailStyle17
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page Section1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.Section1
{page:Section1;}
-->
</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 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'>I would like to add my point here. I think naming or adding db schema
name or column name to FDO class name doesn’t have anything to do with
FDO capabilities, architecture, etc... Such method was choosed to get unique
FDO class name, nothing more. Name could be any kind of random generated character
string (while it is unique inside schema).<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>As you said FDO class supports many geometry columns as
properties and has main geometry property. As far as I can remember it doesn’t
work well with client like MG. I can’t remember all issue I had, I think
one of them was spatial context. To fully support “choose any geometry
property” concept then it should not be main geometry property for FDO
class.<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'>I run into this naming problems across providers while writing
Fdo2Fdo as well as providers. <o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>For Oracle provider we have metadata table for KML it is
configuration file.<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'>My thinking was that solution would be (again) FDO application
layer. In that middle level between application and provider such name
overrides would occur.<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'>Haris<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 0cm 0cm 0cm'>
<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> Tuesday, September 02, 2008 10:15 PM<br>
<b>To:</b> FDO Internals Mail List<br>
<b>Subject:</b> RE: [fdo-internals] Standardising FDO Schema's<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,<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'>I don’t have a problem with defining some simple
conventions such as a default schema name if one isn’t specified explicitly,
especially if it’s a generic issue.<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'>However, regarding the geometry property example in the
discussion where ‘~GeomColName’ is appended to the class name,
there is another approach. FDO allows for more than one geometry property in a
class. There is one that is tagged as the main geometry, but there can be
others in the class. It’s not a common case, but I have seen examples
where additional geometry properties provide additional information for label
points, schematics, or other things. So, it is valid to generate a single
feature class from an rdbms table that has more than one geometry column. Some
providers have chosen to generate separate feature classes with only one
geometry property per class. In some ways, that is easier for a client application
to deal with, but is not an FDO restriction. MapGuide Studio, for instance,
allows you to choose which geometry property to use when creating a layer from
a feature class definition.<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'>FDO has a component for physical schema overrides that was meant
to help the user with mapping the fdo logical elements with a data stores
physical elements. I suspect that fdo users and developers may not be finding
this that helpful as currently specified. Maybe we need to look at this in
conjunction with the other schema mapping discussions to see if improving this
may help the current issues. The theory was that it would provide users with a
way to add explicit mapping from classes and properties to physical elements
such as tables and columns for rdbms’ and also to be able to identify
physical elements from the logical elements when accessing existing schema.
However, because the physical aspects of data stores are specific to the
particular formats, these overrides were provider-dependent, with
provider-dependent api, hence not easy to use with a general client
application. Providers that supported this override saved the override mapping
information in metadata tables or a configuration file. Finding a more general
way to do this by not using provider specific api’s might make this much
more usable. I wonder if anyone has thoughts on this.<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>
<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 0cm 0cm 0cm'>
<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>Traian
Stanev<br>
<b>Sent:</b> Friday, August 29, 2008 11:10 PM<br>
<b>To:</b> FDO Internals Mail List<br>
<b>Subject:</b> RE: [fdo-internals] Standardising FDO Schema's<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'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I agree with Robert on this one. There’s a schema (or
schemas). It has a name. It has classes. The classes have names. From the point
of view of the FDO client app, those remain consistent within the boundary of
the FDO connection. <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'>If the provider is doing some monkeying around with class names
that come from the source database, it’s the provider’s job to be
consistent about handling such mangled names. How the provider does that? Who
cares, as long as it does?<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'>Traian<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 style='border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt'>
<div>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'>
<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> Friday, August 29, 2008 10:54 PM<br>
<b>To:</b> FDO Internals Mail List<br>
<b>Subject:</b> Re: [fdo-internals] Standardising FDO Schema's<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<div>
<p class=MsoNormal>On Sat, Aug 30, 2008 at 5:08 AM, Robert Fortin <<a
href="mailto:robert.fortin@autodesk.com" target="_blank">robert.fortin@autodesk.com</a>>
wrote:<o:p></o:p></p>
<div>
<blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;
margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'>
<p class=MsoNormal>As Orest said, FDO represents the data in different layer Datastore,
Schema and Class. That's the rule. That's the standard. <o:p></o:p></p>
</blockquote>
<blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;
margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'>
<p class=MsoNormal>The fact that some provider doesn't have/require schema
doesn't mean we don't need a generic schema representation in FDO. It's
up to the provider to say what this schema is named and what it maps to (e.g.
default or something else). FDO doesn't impose rules around the name of the
schema. <o:p></o:p></p>
</blockquote>
<div>
<p class=MsoNormal style='margin-bottom:12.0pt'><br>
but currently there is no standard implementation pattern! that's the problem!<br>
which means every implementation can be different!<br>
<br>
should a fdo client really care about which provider and data source is being
used?<br>
<br>
Isn't FDO meant to flatten out all these differences...<br>
<br>
In Orest's example with the oracle database, the database already exists, with
a well known <br>
and understood access pattern right. the database supports the use of
grants, synonyms, <br>
roles etc. there is an existing structure in place. <br>
<br>
create user denver identified by datamonkey<br>
grant select on parcels.denver to denver.parcels<br>
and so on<br>
<br>
Isn't that a much easier and better place to be managing this kind of thing? <o:p></o:p></p>
</div>
<blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;
margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'>
<p class=MsoNormal>For example, removing the schema from SHP would result that
you could have 2 flavors of shp depending on the connection. Connect to a
single file and you get no schema. Connect to a directory and you get a
schema name "default". SHP provider standardize to using
"default" every time.<o:p></o:p></p>
</blockquote>
<blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;
margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'>
<p class=MsoNormal>Also applications relies on that standard: there will be a
schema and it will have a name. This result in consistant representation
of the schemas and classes in a tree view for example. Changing this behavior
has impacts on applications relying on that standard.<o:p></o:p></p>
</blockquote>
<div>
<p class=MsoNormal><br>
I agree the my suggestion of an empty schema would cause headaches, does FDO
have the concept of <br>
a default schema? Ie GetDefaultSchema()? I just know fdo mostly from the
mapguide api side of things <o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><br>
standardising along these lines, primarily for databases providers, means that
any updating <br>
to support this model would mostly involve removing custom provider specific
workarounds....<br>
<br>
A lot of applications wouldn't be affected at all, they just pull whatever
structure the provider represents. <br>
<br>
Those which do, probably have a lot of case statements to handle each different
provider's quirks, <br>
which could potentially be deleted.<br>
<br>
z<br>
<o:p></o:p></p>
</div>
<blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;
margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'>
<p class=MsoNormal><br>
<span style='color:#888888'><br>
Robert</span><o:p></o:p></p>
<div>
<div>
<p class=MsoNormal><br>
-----Original Message-----<br>
From: <a href="mailto:fdo-internals-bounces@lists.osgeo.org" target="_blank">fdo-internals-bounces@lists.osgeo.org</a>
[mailto:<a href="mailto:fdo-internals-bounces@lists.osgeo.org" target="_blank">fdo-internals-bounces@lists.osgeo.org</a>]
On Behalf Of Mateusz Loskot<br>
Sent: Friday, August 29, 2008 11:05 AM<br>
To: FDO Internals Mail List<br>
Subject: Re: [fdo-internals] Standardising FDO Schema's<br>
<br>
Orest Halustchak wrote:<br>
> [...]<br>
> The above is a logical schema. How could that be mapped to physical<br>
> schema? The discussion started with Oracle. Let's say I have an<br>
> Oracle instance called ORCL. The main physical grouping mechanism<br>
> that Oracle has is an Oracle Owner. So, one mapping is that the FDO<br>
> Data Store maps to Oracle Owner, then FDO Schema.Class maps to table.<br>
> That keeps the integrated set of data within a single Oracle owner.<br>
> Another mapping is to map FDO schema to Oracle Owner, i.e. define<br>
> Oracle owners LANDUSE, TRANSPORTATION, etc. But, then how do we<br>
> separate CityOfDenver parcels from CityOfBoulder parcels? I could<br>
> have DENVER_LANDUSE, BOULDER_LANDUSE, etc. There is a third mapping<br>
> possible, and that's to use a separate Oracle instance for each data<br>
> store, but users may not want to set up separate physical instances<br>
> for this purpose, especially if they have a large number of data<br>
> stores.<br>
<br>
<br>
Orest,<br>
<br>
Thanks for the very in-depth explanation of schema naming issues.<br>
<br>
But we still need a consistent way to define and describe all<br>
possibilities of mapping and naming paths in text.<br>
As Zac proves, using only separators (like ::, ~, etc.) is insufficient.<br>
<br>
I think more self-describing approach is needed, perhaps we would use<br>
XML or JSON for naming schemas?<br>
<br>
Best regards,<br>
--<br>
Mateusz Loskot, <a href="http://mateusz.loskot.net" target="_blank">http://mateusz.loskot.net</a><br>
Charter Member of OSGeo, <a href="http://osgeo.org" target="_blank">http://osgeo.org</a><br>
_______________________________________________<br>
fdo-internals mailing list<br>
<a href="mailto:fdo-internals@lists.osgeo.org" target="_blank">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>
<p class=MsoNormal style='margin-bottom:12.0pt'><br>
_______________________________________________<br>
fdo-internals mailing list<br>
<a href="mailto:fdo-internals@lists.osgeo.org" target="_blank">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>
</blockquote>
</div>
<p class=MsoNormal><br>
<br clear=all>
<br>
-- <br>
Zac Spitzer -<br>
<a href="http://zacster.blogspot.com" target="_blank">http://zacster.blogspot.com</a>
(My Blog)<br>
+61 405 847 168<o:p></o:p></p>
</div>
</div>
</div>
</body>
</html>