forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [Patch] tweaks to DTDs and XML
Date Sun, 10 Feb 2002 11:11:12 GMT
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.
 
> 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 :)
 
> <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!

> 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