RE: Fwd: [xml-dev] Data versioning strategy: address semantic, re lation

[Len Bullard <len.bullard@uai.com>]

That's a good frame IMO, Noah.   

Roger framed the Subject as "data versioning" but added two more distinct
and separable domains:  semantics and relationships.  We get into problems
of XML being considered a 'data transport syntax and structure' and then
conflating that with 'application language' where semantics are a
consideration.  As always, the S word opens all kinds of portals to hell
because it is precisely what XML is not targeted to do even though there is
a gray area of names and namespaces.  

These necessary but treacherous bogs are hiding in the phrase "if
*interpreted* per the specification".  Dragons be thar.

One might note Rick Jeliffe's admonitions about the necessity of conformance
language in standards.   This is indeed where many standards past and
present began to fall apart.  SGML was notable in this respect.  That
discussion had just begun in earnest when XML trumped it by removing
features and pointing out to other specifications and standards for those
features it removed (eg, UTF).  This is a little strange when one considers
that the syntax specification should be trivial and in fact, that is why XML
could be as simple as it is.

But this doesn't work for application specifications precisely because of
semantic/behavioral interoperability (Data is portable.  Applications
interoperate.)  The launch of XML muddied this considerably.  Too many
A-listers blithely ignored the S-conformance challenge and the newbies were
pulled into the slipstream.  (NOTE:  I AM NOT TALKING ABOUT THE SEMANTIC WEB
HERE.  I AM TALKING ABOUT APPLICATION INTEROPERABILITY: aka, BEHAVIOR GIVEN
PORTABLE DATA.)

We hit the wall in the VRML world because of originally relying on a precise
syntax specification with a very vague semantic specification.  It was a
case where KISS bit us (no simpler than realistic).  In X3D, we cleaned that
up with a more precise object specification and precise profiles.  We added
complexity by having three syntax specifications but the market made these
necessary (XML, Classic VRML, binary).  The download costs of that turned
out to be minimal (average 4mb clients vs 40mb SL clients).

len


From: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com] 
 
Len Bullard writes:

> The problem then is may be multi-variate:  a change breaks one 
> system but not another.  As in does not break the processing 
> application but does break the help description of the running 
> system.  It isn't just *identifying* the change; it is capturing the
> real and non-real time effects.
> 
> That is the difference between *a* version (identifying the 
> resource) and version control (identifying and executing the 
> process).  Not a new topic here or elsewhere.

Yes, I agree.  More fundamentally, I think we need to be careful with 
terminology.  It's quite common to see discussions in which there is 
debate about whether version 1 of a language is compatible with version 2. 
 I don't think Roger's original note falls into that trap, but I think 
some of the discussion has tended in that direction.  The terminology we 
use can, unintentionally, frame the discussion in ways that hides 
important issues.  I think it's usually more appropriate to ask: "for what 
range of uses can document D authored to conform to the specification of 
version X of a language be safely usable if interpreted per the 
specification for version Y?" and "for what range of uses can >all 
documents< authored to conform to the specification of version X of a 
language be safely usable if interpreted per the specification for version 
Y?"  That latter question tends to capture what one means by language VX 
is/isn't compatible with language VY.  This is just my opinion, but I've 
found it a useful way to frame things.


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.