Re: "easy-fix" bugzilla keyword becomes "gnome-love"

On Sat, 2005-03-12 at 11:02 +0100, Michèle Garoche wrote:
> Le 12 mars 2005, à 1:48, David Malcolm a écrit :
> > On Fri, 2005-03-11 at 16:47 +0100, Michèle Garoche wrote:
> >> Le 11 mars 2005, à 4:05, David Malcolm a écrit :
> >> 1 - I may add missing elements to the version of docbook used in the
> >> dispspecs, i.e. 4.1.2
> >
> > What elements are we missing?
> I've just have a quick look at the elements. Here's the result (not 
> finished yet):
> abbrev
> accel
> ackno
> action
> affiliation
> alt
> appendixinfo
> area
> areaset
> areaspec
> arg
> 
> As for revision history: we're missing revdescription. And the name for 
> revnumber is Revision, instead of Revision Number. I have no idea if 
> both chock or not.
> What is sure is there is a problem with the elements hierarchy 
> visibility.
> 
> A typical revhistory with revremark is as follows:
> <revhistory>
> <revision>
> <revnumber>&manualversion;</revnumber>
> <date>10/02/2005</date>
> <authorinitials>MG</authorinitials>
> <revremark>Updated to cssed versions &softwareversion;, improved 
> stylesheets.</revremark>
> </revision>
> <revision>
> <revnumber>1.13</revnumber>
> <date>29/12/2004</date>
> <authorinitials>IRS</authorinitials>
> <revremark>Added instructions for installation.</revremark>
> </revision>
> </revhistory>
> 
> But I have no access to date, authorinitials, revnumber, and revremark 
> inside conglomerate's normal panel, though when seeing raw xml, date, 
> revnumber and revremark are here (not authorinitials though), but text 
> is not accessible. I don't understand exactly how the access to text is 
> handled. If you can explain it, I may correct that and ensure that all 
> elements are displayed correctly and that visibility and access to text 
> modification is given where it is needed.

I belatedly filed the above here:
http://bugzilla.gnome.org/show_bug.cgi?id=303188


> >> 2 - This 4.1.2 version is pretty old, current version is 4.4.
> >> Hence not giving access to the newer elements.
> >> How should this be handled?
> >
> > Good point.  We need a smarter way of handling all the different 
> > DocBook
> > versions out there.
> >
> > Maybe either take the union of all elements from all versions of 
> > DocBook
> > ever,
> Not sure, it is good, since it will allow the user to insert non valid 
> tags for the current spec, if any. But as spec is not mandatory, it may 
> be an option too. Then the validation should take care of this if there 
> is a docbook declaration in the file.
> 
> >  or maybe something smarter; it'd be nice for Conglomerate to
> > "know" about the different types.
> >

Lots of good ideas here; I created a bug and posted a link back to this
email here:
http://bugzilla.gnome.org/show_bug.cgi?id=303190


> > So how about having multiple DocBook.xds files, which specify a 
> > dispspec
> > for each version of the DocBook format.... BUT... each one simply
> > includes a shared "do everything" external entity that has the union of
> > the elements.  I don't know how well that would play with the i18n
> > framework though.
> I'm not sure to understand what you mean by a shared "do everything" 
> external entity:
> 1 - just the shared elements among docbook versions?
> 2 - And then a spec for each version with only the non shared elements?
> Not sure it is good, as there are always changes between docbook 
> versions, then you must constantly update all the files.
> 
> Maybe, it could be possible to have only one docbook.xds.in file with 
> two new variables:
> 1 - minimum version where the element can occur,
> 2 - maximum version where it can occur,
> inside the docbook.xds.in (that's the way it is done in docbook 
> official specification, hence it is easy to check if the definition is 
> right).
> 
> By default: min=0, max=0, means allowed in all versions; if min > 0, 
> then forbidden in version < min; if max < currentversion, then 
> forbidden in currentversion.
> 
> Though I don't know how it is possible to integrate it in the code 
> which displays possible elements.
> 
> >>
> >> a - Another dispspecs?
> >> b - A variant on the docbook dispspec excluding obsolete elements and
> >> including new ones
> >
> > Not sure this would be needed; take the union.  Most of the data should
> > really be coming from the DTD/schema, and that would give the correct
> > set of elements.  The dispspec just tells you how to visualise an
> > element, it doesn't replace schema (apart from the case where you don't
> > have a DTD/schema, in which case you end up with the "here's a set of
> > elements in a dispspec" "pseudo-schema").
> Oh, OK so that's the official schema which gives the correct set of 
> elements, so part of what I said above is inappropriate. You're right a 
> huge union of all docbook elements may be the best way, but then the 
> dispspec should handle case below.
> 
> > Unless the visualisation of
> > an element should vary between versions of a doctype (ugh!)
> Yes, it occurs sometimes, that some element changes from inline to 
> block display.
> 
> 
> Michèle
> <http://micmacfr.homeunix.org>