[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Do We Need James Clark to get Good Recs?


james clark oasis
[Didier PH Martin]

Thank you, Didier, for such a a thoughtful and cogent reply.

Cheers,

Tom P

> 
> I guess it all ends up in the "knowledge management" courtyard. Like you
> said, a good spec has to be simple to be accepted by the neophytes. It's
> only when a domain is well understood that a spec could be made simple
> enough for mass consumption (I mean here, developers :-). Since you are
> also part of DSSSL history, what I'll say will be only a reminder for
> you. So, this is for the others wanting to understand...
> 
> Now, a little bit about history. We tend to forget that before XSLT we
> got a lot of experimentations and learning occurring with DSSSL. DSSSL
> was based on the premise that it should be able to transform Groves. So
> to speak, if an Excel document stored in a proprietary format could be
> transformed into a grove, then it could be transformed into another
> grove like for instance, an XML based structure or into standard
> formatting objects. However, this part of the spec never took off
> because, no freely accessible grove engines were available and Jade
> didn't supported external grove nor was it supporting the transformation
> part of DSSSL. Bottom line, we never experimented what manipulating
> generic grove would be with a standard language. But, James added a nice
> feature allowing us to create our own formatting object, for instance,
> SGML element, attributes, etc... People using Jade started to use that
> feature to perform transformation from one SGML structure to another.
> Some consultant needed an SGML instance to be transformed into different
> formats and then we got a MIF backend (FrameMaker), a TeX backend. All
> these people got a forum with the Mulberry mailing list (i.e. the DSSSL
> mailing list still existing today).
> 
> There we go; we got the right environment for learning:
> 
> a) a freely available implementation (and free $$)
> b) a small group of users and a community allowing them to share (the
> DSSSL mailing list + the consultant using it and expending it)
> b) Somebody learning from this interaction and synthesizing this
> knowledge.
> 
> Then we got a version 2 with XSLT, it was, in fact, the result of
> several years or experimentation and feedback. DSSSL was version 1.0 and
> XSLT the 2.0 version. The rules were replaced by templates and the
> matching mechanism simplified. These things were present in DSSSL but
> simply expressed in more complex ways. And the DSSSL SGML backend
> provided the right environment to learn about the template mechanism.
> 
> I guess that what is happening right now with some specs is that we are
> in the middle of the experimentation process and these people are
> learning. If these groups have a high turnover, then these groups can
> hardly learn since this knowledge evades when some key people are
> quitting the group. 
> 
> All in all, this is knowledge management process.
> a) Create a thesis, build a prototype
> b) Get people to use you prototype and get feedback
> c) Correct the thesis and the prototype on the basis of the feedback you
> got.
> 
> If you can reduce the time for each cycle (from a to c) then you are
> learning at a faster pace. This is why some said "fail early, fail
> often" they simply meant accelerate the learning cycle by reducing the
> time take at each stage.
> 
> 
> So, even if James is very very talented, we shouldn't forget the
> history. This could at least prevent us to repeat the errors of the past
> or to understand that we human have some ways to learn when we explore
> unknown territories.  As SGML/XMLers, do we?
> 
> So, to answer to the first question: It is only when an group has found
> ways to learn (as some scientific communities) that it can improve its
> knowledge. Science taught us that a good way is to get at least two
> kinds of individuals in a group: Experimenters and theorists. Obviously
> the experimenters help to invalidate the theories or simply to grab new
> data to be explained by theorists. In a world like XML, we need
> implementations that people can play with (experimenters) and people
> writing specs (theorists) if the theorists do not pay attention to the
> experimenters, the feedback loop is broken and the group stops learning.
> If the experimenters do not have an incarnation of the theories (a
> concrete implementation) then again, the feedback loop is broken. If the
> experimenters need to buy the implementation, then the loop may either
> be broken or lengthened.
> 
> My 0.02 Euro, 0.02 CAN$ and 0.02USD (the advantages of being
> multi-cultural :-)
> 
> Cheers
> Didier PH Martin
> http://www.didier-martin.com
> 
> 
> 
> 
> 
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
> 
> The list archives are at http://lists.xml.org/archives/xml-dev/
> 
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
> 
> 


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.