OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [emergency] Circle and Polygon

While I understand and mostly agree with Art on the general principle 
of preventing differing notions of "Best"  from becoming enemies of 
the "Good" we are attempting to advance, I am pretty comfortable with 
GML as a means to that end. This is especially true if we can reduce 
the danger of over specified polygons. Len and I come from a mutual 
interest in 3D where, depending on the application, polygon reduction 
(in numbers of triangles stitched together into meshes (a slightly 
different by generally similar situation) is essential to 
performance, so we understand the problem. I happen to think that 
either a rule of thumb, or a specified limit to the number of 
lat/long points might serve to solve the problem, such that 
practitioners can automatically apply an optimization algorithm 
before sending a message.


At 6:05 PM -0700 6/10/05, Art Botterell wrote:
>On Jun 10, 2005, at 6/10/05 11:04 AM, Bullard, Claude L (Len) wrote:
>>When gardening, one doesn't 'let a thousand flowers bloom'.
>>One prunes relentlessly and daily.
>Alas, I suspect that what we're involved in here is more like 
>forestry than horticulture.  And after all, having each specialist 
>community tend its own garden is pretty much what led to 
>interoperability problems in the first place.
>Instead of serving one particular constituency, we're trying to 
>address issues at a higher level of abstraction, one that bridges a 
>number of specialties.  As with any attempt at global optimization, 
>it's unavoidable that the results will be slightly suboptimal for 
>each individual user.  So I think we may want to be careful about 
>carrying efficiency arguments too far... we're rarely going to find 
>a single take on efficiency that every stakeholder shares.
>Also, I think we need to consider what our role should be.  Are we 
>proposers and presenters of standards, or just repackagers of other 
>folks' work?  Putting that another way, is a pre-existing standard 
>always better just because it came first?  If not, how much weight 
>does precedent deserve?
>Further, I think we need to guard against turning XML into a 
>next-generation stovepipe by moving application logic into messaging 
>data structures.  Some XML folk, in particular, seem to prefer doing 
>every possible bit of processing in the parser.  That's 
>understandable, but might that path lead us toward petrification as 
>loosely coupled and flexible web services get trapped in a dense 
>matrix of hyper-specified data structures?
>Finally, I'll call for a committment to humility on everyone's part.  
>What we're trying to do here, in terms of cutting across 
>disciplinary and organizational boundaries, hasn't been done before. 
>There are no real experts... we're all explorers.  If we let 
>ourselves become personally attached to particular theories, 
>techniques or precedents, this whole undertaking could bog down in 
>exactly the sort of factionalism some skeptics have predicted.
>The question, IMHO, isn't what's "right"... we really don't know 
>that, even though each of us may have strongly-held theories.  The 
>question for now is what we can put together that will serve as a 
>productive platform for further exploration and learning.  And it's 
>in that spirit that I urge we keep our structures as simple as 
>possible, on the theory that it'll be easier to add specificity 
>later than it will be to back out of premature choices.
>In short, let's not let our ideas of the Best become the enemies of the Good.
>- Art
>To unsubscribe from this mail list, you must leave the OASIS TC that
>generates this mail.  You may a link to this group and all your TCs in OASIS

Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-849-2309

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]