forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <cross...@indexgeo.com.au>
Subject Re: [Patch] tweaks to DTDs and XML
Date Sun, 10 Feb 2002 12:44:27 GMT
Stefano Mazzocchi wrote:
> David Crossley wrote:
> > Stefano Mazzocchi wrote:
> > > David Crossley wrote:
> > > > Stefano Mazzocchi wrote:
> > > > > David Crossley wrote:
> > > > > > Hi Stefano, my usual thing when i start out on an XML
> > > > > > project is to validate one of the existing XML documents
> > > > > > to be sure that the infrastructure is set up properly.
> > > > >
> > > > > Yeah, I didn't do that... because I knew that somebody else
> > > > > would have done it :)
> > > >
> > > > Please do not rely on that.
> > >
> > > David, it is by leaving little itches for people to scratch that I
> > > managed to make a good open development community.
> > 
> > <snip summary="useful and valid explanation of the Stefano
> > mechanism for recruitment"/>
> > 
> > > Those imperfections that I don't care about are 'ego traps' and I leave
> > > them around because I'm a person hunter: I don't care about good
> > > software, I care about good people and having them in my team.
> > >
> > > Those 'ego traps' are the way I do recruiting for open development
> > > communities.
> > 
> > I do understand your approach. However, i feel that it may
> > be flawed. Not everyone is driven by ego. Some, like me,
> > are driven by frustration and wanting to get beyond the basic.
> 
> Sorry, I used 'ego' in his original latin meaning: 'ego' means 'my own
> self'.
> 
> For 'driving by ego' I mean: driving by your view of the world, your
> taste, your judgement, your understanding, your metrics, your pleasure,
> your 'aesthetic' sense.
> 
> > These types may easily leave the project, even though there
> > is no need or intention to turn them away. Actually i think
> > that the ego-driven types are not as useful.
> 
> Oh, here you are talking about 'ego' in the english sense where it has a
> negative connotation: 'ego' for 'sellfishness'. No, that was not what I
> meant and I agree that blind sellfishness is harmful to a community.

Damn the English langauge, and let us not even mention the
American version.

> > Perhaps a better approach is to document such known
> > imperfections in a "To Do" list (even just as one-liners).
> > In that way the ego types can still blow their trumpet about
> > having fixed a major problem, while other types can
> > consistently get on with the job.
> 
> That's not my experience.
> 
> It is *far* better to implement something that doesn't work (really, I
> mean, doesn't even compile!) than to write a full doc about what is your
> with and your dream.
>
> The people around OSS are so bugged by imperfections that they *have* to
> fix them. So, a good way to force them to do something, is creating
> imperfections :) (not on purpose, but avoiding the polishing of things
> so that they have something to do, something to learn and a easy way to
> get into the fun)
>
> Well, this doesn't work for design: this is why I care so much about
> architectural design: but for everything else, well, it works :)

This is where i too put my focus. The ability to somehow perform
XML validation and guarantee a reliable SAX stream is
"architecture" in my book.

I suspect that this is why i started this thread. I saw something
that i consider to be fundamental, and thought that it was not
being well-considered.

Anyway, i think that we have it sorted out now. 
 
> > <snip summary="encouraging a strong community is of
> > primary importance"/>
> > 
> > <snip summary="Stefano borrowed Sam's asbestos
> > underwear :-)"/>
> 
> Admittedly, Sam and I have been greatly cross-pollinating each other and
> the more we work together, the more I see something *really* strong
> being built as a foundation of our communities.
> 
> Forrest should be the way to carve this in stone and transmit this to
> those who will come after us.
>  
> > > > On the cocoon-dev list i am having trouble getting people to
> > > > consider validation issues.
> > >
> > > You do? from where I stand, I think you did a great job and
> > > people are (admittedly slowly) listening.
> > 
> > Thanks. The entity resolver was the main infrastructure step.
> > Validation is the next step in building a solid framework. It did
> > function for a while with Cocoon build docs, but recently fell
> > over when Vadim fixed a bug with XSLTProcessorImpl.
> > Validation then hit the namespace wall and squashed itself.
> 
> Yes, but this is not your fault, or Cocoon community's fault: it's the
> fact that the XML Infoset made DTDs obsolete.
>  
> > > It might be that the problems are the DTD technology which
> > > is not powerful enough in a heavily namespaced world
> > > like Cocoon.
> > 
> > Agreed. However, DTDs are still a useful way to define
> > the allowed structure of an XML instance. 
> 
> Well, I disagree. Look at the validation issues we are having: if you
> include an external fragment, the ID's don't work anymore.... external
> entities should be avoided and xinclude should be used... but there is
> no definition of the 'process' that an XML document must undergo when
> being parsed (validation should be done before or after xinclude
> expansion?)
> 
> This flow-description (somewhat similar to the cocoon sitemap, but for
> general XML documents) is what James Clark has been preaching for... but
> the problem is *so* complex that might not even have a single solution.
> 
> But we do have a solution: if we use a RelaxNG validating transformer in
> Cocoon, we have the ability to use Cocoon itself as a validator, thus
> avoiding the plague of DTDs!

Wonderful. That is the sort of thing that i have been visualising.
After we have done some preliminary investigation of RelaxNG
the idea could be floated on the cocoon-dev list. I will have a
little look now and report to forrest-dev under a fresh thread.

Many thanks for the discussion about encouraging the community.
It is valuable to understand the vision of others.
--David

> > Cocoon should
> > still be able to perfom basic validation, at least of its own
> > configuration files and shipped doco. I will persist there.
> 
> We have already hit a wall with external IDs, I think it's useless to
> continue in this direction.
> 
> > > Have you ever considered switching over to RelaxNG?
> > 
> > Mostly definitely. From the little investigation that i have
> > done, it seems like the way to go. I intend to bypass
> > XML Schema and go straight to RelaxNG.
> 
> Yep, same here.
> 
> > > Should we for Forrest?
> > 
> > I do think so. We should investigate RelaxNG as we go.
> 
> Totally agreed.
>  
> > However, DTDs are here-and-now and they provide a
> > useful basic validation infrastucture. 
> 
> agreed.
> 
> > I see DTDs having
> > an additional role. They clearly define the structure of an
> > XML instance for documentation purposes.
> 
> Well, I've been thinking about using RelaxNG information not only as a
> validation purpose but also as an authoring-driving set of constraints
> and I think it is possible to use it.
> 
> (expecially because RelaxNG doesn't mess with the infoset and with IDs,
> unlike DTDs and Schemas)
>  
> > So i think that we still need solid DTDs to begin with.
> 
> Yeah, well, I agree, but we already have to get rid of those IDs so we
> are already struggling to keep up (and we don't have namespaces yet!)
> 
> > Then those DTDs can be automatically converted to basic
> > RelaxNG which can be subsequently fine-tuned. In passing
> > i have seen some tools for converting well-written DTDs
> > into RelaxNG - i will investigate.
> 
> Ok, cool.
>  
> > <snip/>
> > > > That is my main point. It is so easy to make blunders
> > > > when authoring XML instances or when designing DTDs.
> > > > One cannot rely on the eye (or even on editing tools)
> > > > and must use a validating parser.
> > >
> > > or rely on picky people like you :) [sorry, I had to say that]
> > 
> > However, i do not have spare time to be "Capitan Validation".
> 
> Well, none of us has spare time, David. But none of us can resist
> scratching our itches.
> 
> For sure, if an itch turns into a plague, it's not fun anymore. But I'm
> fully aware of this and I don't make this happening, otherwise, you
> wouldn't be here. :)
> 
> > I would like to be able to rely on a solid XML framework and
> > get on with contributing other stuff.
> 
> +1
> 
> -- 
> Stefano Mazzocchi      One must still have chaos in oneself to be
>                           able to give birth to a dancing star.
> <stefano@apache.org>                             Friedrich Nietzsche
> --------------------------------------------------------------------


Mime
View raw message