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


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] Do We Need James Clark to get Good Recs?

[ Lists Home | Date Index | Thread Index ]

[Didier PH Martin]

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


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>


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

Copyright 2001 XML.org. This site is hosted by OASIS