XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
RE: [xml-dev] RE: Caution using XML Schema backward- or forward-c ompatibility as a versioning strategy for data exchange

I agree with Stephen and Michael.  These are the kinds of operational
information that one does want because they occur frequently.  My best
example is border measurements such as county or state lines where a river
is part of the border.  This one is gnarly because it is the centerline of
the river that is used and the river changes daily and sometimes abruptly.
One tries to avoid this but it is an example where imprecision causes real
jurisdiction problems (there is a movie from the 50s based on that exact
scenario).

Yes, SGMLers faced the same problems.  There are different factions for the
best solution but given a desire/requirement to keep the artifact purely
declarative, comments were favored.  An authoritative version could be
acquired.  But SGML spawned in the day of infrequent exchanges and
centralized ownership/management.  We knew that hypertext systems couldn't
work quite like that but didn't anticipate the ferocious resistance to
downloading DTD/Schemas as part of the transaction, or the somewhat mystical
attachment to URL/URIs and resistance to URNs.

So it comes down to:

1.  Means
2.  Probability of precision (did the river change course)
3.  Tolerance of ambiguity vs costs of precision.

Originally what I am *resisting* is any broad claims that semantics are
always required and particularly that they have to be acquirable *just in
time* (late bound).  That can be the case but not always.   Again, from my
perspective, there is a curve where at some point along it, there is an
abrupt transition from specification to application possibly based on the
costs of acquiring and maintaining all of the multiple specifications over
the cost of simply mailing someone a copy of the running code.  

It's an old problem:  the cost of the number of degrees of freedom for any
given party to a transaction.  That is the simple model.  The real world
model is open data exchange over proprietary or singleton applications
(Flash vs SVG, doc vs HTML, etc.).  XML was devised as a simple means to
loosely couple.  Attempts to enable tighter coupling resolve to
specifications with tight implementation and conformance requirements or a
single application winning (the usual result; see IE), or a fractured market
of quickly spawning incompatible applications (see the current 3D market).

len


From: bryan rasmussen [mailto:rasmussen.bryan@gmail.com] 
 
On Jan 2, 2008 11:42 PM, Stephen Green <stephengreenubl@gmail.com> wrote:
> To elaborate:
>
> taking Roger's scenario:
>
> > [in version 1]
>
> > <distance>100</distance>
>
> > means "distance from center of town."  Accordingly, the client's
> > application does calculations based on that meaning.
>
> > In the version 2 data the syntax is changed in a forward-compatible
> > fashion.  In addition, the semantics of the <distance> element is
> > changed to "distance from town line."
>

actually I really hated that example because I found it somewhat
unrealistic for something that would actually happen, and somewhat
data-apocalyptic.

Cheers,
Bryan Rasmussen
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.


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


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS