RE: [XMLVersioning-41] Scope

I'm somewhat confused by what you are calling a "protocol".  I think you are calling XML 1.x, XPath, XPointer, XQuery, etc. protocols.  I tend to think of the Web in terms that the AWWW talks about, that is formats and interactions, where interactions=protocols.  The split between formats and protocols seems to be W3C + OASIS doing formats and IETF doing protocols.  Some ietf examples are tcp, ip, udp, smtp, ftp, http, sip.  

I think it helps to keep thinking in terms of protocols and formats in terms of the AWWW.

Of the formats, there seem to be at least 2 major facets: function based and non-function based.  The languages that you have mentioned (Xpointer, XPath, etc.) are function based languages, and they are also not XML based.  

But I do think that a significant portion of work that the W3C is doing is XML based.  Some examples are XHTML, Voice, WS-Addressing, SOAP, WSDL, etc.  These, and the many other users of XML, are all well served by an XML Schema based e/v story.

However, the point that XML schema is not the only language has been factored into the TAG work.  

I interpret your comments to highlight that there are also languages that are function based languages.  It is probably that function e/v is different than data versioning, that is e/v of f(x) has different issues that e/v of x.  Now there is alwayas a tension in computing between when to treat data that is an opcode as data or as an opcode, but I think we can focus on treating them separately.  

A finding on E/V of functional languages would probably be very useful.  But I re-express my concern that that may be too big a scope for the TAG to pursue.  That sounds more and more like a doctoral thesis to me.  It may be that it is impossible to separate the e/v of the two different types and a data only format e/v finding is impossible to concretely write.  I will certainly further ponder this distinction you have highlighted.

As for the minor point about backwards/forwards compatibility, I basically used the foldoc definition for backwards compatibility.  Reprised, it's

"backward compatibility
Able to share data or commands with older versions of itself, or sometimes other older systems, particularly systems it intends to supplant. Sometimes backward compatibility is limited to being able to read old data but does not extend to being able to write data in a format that can be read by old versions. 

For example, WordPerfect 6.0 can read WordPerfect 5.1 files, so it is backward compatible. It can be said that Perl is backward compatible with awk, because Perl was (among other things) intended to replace awk, and can, with a converter, run awk programs."

This definition focuses on software's ability to read older versions.  There is clearly a difference between software evolution and language evolution.  It is certainly possible that a language could evolve incompatibly but the software is compatible.  XML 1.1 vs XML 1.0 is a good example, where I can write a parser that groks XML 1.0 and XML 1.1 yet XML 1.1 is incompatible with XML 1.0.  

The key part of the definition supporting the finding's view is the "able to share data with older versions of itself" section, where itself is the language.  Thus I think "A language change is backwards compatible if newer processors can process all instances of the old language" is accurate.

I'm getting the impression that the TAG finding as it stands is really missing the mark for you.  The things that are currently in it (data formats + predominantly xml schema) are not the areas that you are interested in, which seem to be functional formats without much concern for XML Schema.

Cheers,
Dave
> -----Original Message-----
> From: Bjoern Hoehrmann [mailto:derhoermi@gmx.net]
> Sent: Tuesday, February 22, 2005 6:41 AM
> To: David Orchard
> Cc: www-tag@w3.org
> Subject: [XMLVersioning-41] Scope
> 
> * David Orchard wrote:
> >I am interested in exploring language design beyond "simply" xml and xml
> >schema, but I retain the worry that the more abstract the discussion,
> >the smaller the audience or the less useful particular audiences will
> >find the material.  The finding already is almost too general for my
> >tastes as I believe that XML Schema is the most popular choice of schema
> >language for xml design.
> 
> I am concerned about the scope of the TAG issue XMLVersioning-41 and
> the draft findings so far. I think the scope should be generalized to
> Protocol Evolution and Re-use with a focus on providing material that
> will help protocol designers to make design decisions relative to these
> issues.
> 
> The current focus on XML Versioning misses discussion of design issues
> that were relevant to the design of XML 1.x and XML Namespaces 1.x; as
> such issues are likely relevant to the design of protocols that are not
> based on XML 1.x such as XPath, SPARQL, Notation3, N-Triples, XPointer,
> XQuery, CSS, and (transcending from the bare syntax level) the DOM, it
> is important to provide a broader perspective on these issues.
> 
> I think there is a common set of concepts and terminology that apply to
> protocols independend of choice of specific syntax such as XML syntax,
> and I consequently suggest that the first part of a finding on protocol
> evolution and re-use provides a clear and detailed discussion of common
> concepts and terminology including a general discussion of the impact
> of design decisions relative to these concepts, without recommendations
> towards making specific design decisions.
> 
> This would take into account that a major part of W3C's work does not
> focus on the design of new XML-based document formats and that design
> decisions relative to these issues vary greatly on a variety of factors,
> for example, XML-based document formats for Business-to-Business SOAP-
> based data-oriented Web Services are subject to different considerations
> than formats developed in W3C's Interaction Domain.
> 
> This would provide a solid ground for all discussions around protocol
> evolution which is indeed more important than how to use XML Namespaces
> one way or the other. In particular, it is important to use common terms
> to discuss such design issues, to cite just one example from the current
> draft,
> 
>   A language change is backwards compatible if newer pro-
>   cessors can process all instances of the old language.
> 
> This is not how many people use this term, it is often used to mean
> 
>   A language change is backwards compatible if old pro-
>   cessors can process most instances of the new language.
> 
> The second part of the finding should discuss these concepts relative to
> the design of XML as an architectural platform and design considerations
> for XML-based formats relative to these concepts, again including a dis-
> cussion of the impact of specific design decisions. This would include
> use of XML Namespaces in XML document formats and use of HTTP to trans-
> port XML document formats in the context of evolving formats and should
> strive to build consensus around some of the relevant concepts as far as
> that would be beneficial (and I suggest that for many of the suggested
> good practises that does not apply.)
> 
> If the TAG is really considered the best place to develop W3C XML Schema
> Primers there could be a third part discussing how to implement design
> decisions based on the other parts of the finding and general W3C XML
> Schema authoring guidelines, but I suggest it be dropped.
> --
> Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
> Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
> 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Tuesday, 22 February 2005 17:30:13 UTC