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

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.

>> 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.
>
> 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>

_______________________________________________
Conglomerate-devel mailing list
[email protected]
http://lists.copyleft.no/mailman/listinfo/conglomerate-devel