[Conglomerate] TEI/TEI lite support

[Walter H. van Holst]

Hello,

I'd like to know if any TEI and/or TEI-lite support is planned for
Conglomerate.

Regards,

Walter

[Steinar Bang]

Post by Walter H. van Holst
I'd like to know if any TEI and/or TEI-lite support is planned for
Conglomerate.

I couldn't find anything about this in the Bugzilla bugs database, so
I added the following enhancement request:
http://bugzilla.gnome.org/show_bug.cgi?id=133060

Please extend and add to this with any information you think is
missing.

[Dave Malcolm]

You may be able to add the support yourself!

If you have a DTD file to hand, then run Conglomerate, and select
File->Import, then browse to the DTD file. You should get a "File
Import Options" dialog. Make sure "Convert DTD into a Conglomerate
Display Specification" is selected and press OK.

Alternatively, load an example document of the type you wish to support,
ideally one with a Document Type Declaration referencing a PUBLIC ID
with a SYSTEM ID referencing the document type definition via http .

Conglomerate will complain that it doesn't recognise the document type,
and ask if you wish to load it anyway. Click on the Force button, and
Conglomerate will generate a display specification as it loads the file.
You can then go to the Tools menu and select Dump Display Spec.

In either case, Conglomerate should create a new "display specification"
file. You should save the file into the examples subdirectory, giving
it a ".xds" extension. You should then edit examples/Makefile.am and add
the filename of the new display specification to dispspec_DATA. You
should then re-run make, then (possibly as root) make install, and
restart conglomerate. Try loading a TEI document; Conglomerate should
now handle it without complaining. Please email the conglomerate-devel
mailing list with a patch that adds the document type, so that we can
add it to CVS, and into the next release.

Once you have a working xds file for a document type, you can fine-tune
it in some of these ways:

* Change whether elements are "structural" or "span" elements. The
display specification generation routine tries to guess this
based upon the example document and on the DTD, but it sometimes
makes mistakes.

* Set up human-readable names for elements, together with
descriptions of what they do. Currently this is in English only,
though we plan to allow localisable versions of these strings
(patches welcome!)

* Set up icons for elements, for use in the menus and in the main
widget.

* Write custom XPath rules for generating the title string to be
used for an element.

* Use plugins to better represent an element. For example, there
are already plugins aimed at rendering paragraphs, and items
within lists. You can even create custom property dialogs for an
element type, those this requires writing some code.


The best thing to do is to look through the examples/docbook.xds file,
which has examples of how to do these things, and to ask on the
conglomerate-devel mailing list.

Post by Walter H. van Holst
Hello,
I'd like to know if any TEI and/or TEI-lite support is planned for
Conglomerate.
Regards,
Walter

[Roberto Rosselli Del Turco]

First of all, I'm delighted to see a fellow TEI encoder on this list. I
will try to comment on Dave's suggestions.

Post by Dave Malcolm
You may be able to add the support yourself!

Unfortunately it's not so simple for full TEI stuff.

Post by Dave Malcolm
If you have a DTD file to hand, then run Conglomerate, and select
File->Import, then browse to the DTD file. You should get a "File
Import Options" dialog. Make sure "Convert DTD into a Conglomerate
Display Specification" is selected and press OK.

Problem is, you don't have a single dtd file for the full TEI
guidelines, you have several, and those I tried to import failed with
lots of errors, possibly because of their intertwined nature.

I managed to load the teixlite.dtd, though, and save a display
specification for Conglomerate. Same for the Digital Scriptorium dtd,
which is based on a single dtd file very similar to the TEI Lite one.
I still haven't had the time to refine the resulting .xds files, if you
(Walter, I mean :) are interested we can work together on it,
subdividing work and checking each other's files.

Post by Dave Malcolm
Alternatively, load an example document of the type you wish to support,
ideally one with a Document Type Declaration referencing a PUBLIC ID
with a SYSTEM ID referencing the document type definition via http .
Conglomerate will complain that it doesn't recognise the document type,
and ask if you wish to load it anyway. Click on the Force button, and
Conglomerate will generate a display specification as it loads the file.
You can then go to the Tools menu and select Dump Display Spec.

This doesn't fit very well with such rich dtds, although it seems to
work better on regular TEI files, because you always end up with a small
subset of the TEI elements.

Post by Dave Malcolm
Once you have a working xds file for a document type, you can fine-tune

Thanks for this list, I will look into it ASAP. Walter, drop me a line
if you're interested in joining forces on this, even if only to check my
.xds files with your TEI documents.

Ciao

[Dave Malcolm]

Post by Roberto Rosselli Del Turco
First of all, I'm delighted to see a fellow TEI encoder on this list. I
will try to comment on Dave's suggestions.

Post by Dave Malcolm
You may be able to add the support yourself!

Unfortunately it's not so simple for full TEI stuff.

Post by Dave Malcolm
If you have a DTD file to hand, then run Conglomerate, and select
File->Import, then browse to the DTD file. You should get a "File
Import Options" dialog. Make sure "Convert DTD into a Conglomerate
Display Specification" is selected and press OK.

Problem is, you don't have a single dtd file for the full TEI
guidelines, you have several, and those I tried to import failed with
lots of errors, possibly because of their intertwined nature.

Or because of bugs in my code :-(

In theory, perhaps we could have multiple xds files, one for each DTD,
with some kind of entity referencing thing going on to reuse the common
features.

(I really need to take a good look at TEI before commenting further I
think - looks like it'd be a nice format to add, and wouldn't be too
hard, I think. Assuming that the format is "free", and that we don't
have to pay licensing fees or similar...)

OK - I just had a look through the DTD structure of TEI and now I'm
scared! Lots of fragments of DTD information in multiple files. The
good thing is that Conglomerate xds files are quite "sloppy", and it
doesn't really matter if you have elements missing, or extra elements.

It might even be worth redesigning how Conglomerate's xds files are
structured to make it easier to handle TEI...

Post by Roberto Rosselli Del Turco
I managed to load the teixlite.dtd, though, and save a display
specification for Conglomerate. Same for the Digital Scriptorium dtd,
which is based on a single dtd file very similar to the TEI Lite one.
I still haven't had the time to refine the resulting .xds files, if you
(Walter, I mean :) are interested we can work together on it,
subdividing work and checking each other's files.

Please can you post your xds files to this list! It'd be good to add
them to CVS, and into the tarballs. That way we can have TEI support
for everyone, from install. Whenever you find an element that isn't
supported, just add it to the xds file and post a patch to the list.

This would probably be a single "tei.xds" file, or maybe a "tei.xds.in"
file so that we can support translations of the element names.

Are there any sample instance documents that we could freely
redistribute in the "examples" subfolder? This is much nicer from a
testing point-of-view.

Post by Roberto Rosselli Del Turco

Post by Dave Malcolm
Alternatively, load an example document of the type you wish to support,
ideally one with a Document Type Declaration referencing a PUBLIC ID
with a SYSTEM ID referencing the document type definition via http .
Conglomerate will complain that it doesn't recognise the document type,
and ask if you wish to load it anyway. Click on the Force button, and
Conglomerate will generate a display specification as it loads the file.
You can then go to the Tools menu and select Dump Display Spec.

This doesn't fit very well with such rich dtds, although it seems to
work better on regular TEI files, because you always end up with a small
subset of the TEI elements.

Post by Dave Malcolm
Once you have a working xds file for a document type, you can fine-tune

Thanks for this list, I will look into it ASAP. Walter, drop me a line
if you're interested in joining forces on this, even if only to check my
.xds files with your TEI documents.
Ciao

[Steinar Bang]

Post by Dave Malcolm
Please can you post your xds files to this list!

Or perhaps attach them to the enhancement request?
http://bugzilla.gnome.org/show_bug.cgi?id=133060

Post by Dave Malcolm
It'd be good to add them to CVS, and into the tarballs. That way we
can have TEI support for everyone, from install.

Indeed.

Post by Dave Malcolm
Whenever you find an element that isn't supported, just add it to
the xds file and post a patch to the list.

Do you prefer patch postings to the list, to attachments in bugzilla?

[Dave Malcolm]

Post by Steinar Bang

Post by Dave Malcolm
Please can you post your xds files to this list!

Or perhaps attach them to the enhancement request?
http://bugzilla.gnome.org/show_bug.cgi?id=133060

That would also be good.

Post by Steinar Bang

Post by Dave Malcolm
It'd be good to add them to CVS, and into the tarballs. That way we
can have TEI support for everyone, from install.

Indeed.

Post by Dave Malcolm
Whenever you find an element that isn't supported, just add it to
the xds file and post a patch to the list.

Do you prefer patch postings to the list, to attachments in bugzilla?

Attachments to Bugzilla are less likely to get lost.

In some ways the ideal is to attach the patch to Bugzilla, but to also
send a short email to the list to draw more attention to it.

[Roberto Rosselli Del Turco]

Post by Dave Malcolm
In theory, perhaps we could have multiple xds files, one for each DTD,
with some kind of entity referencing thing going on to reuse the common
features.
(I really need to take a good look at TEI before commenting further I
think - looks like it'd be a nice format to add, and wouldn't be too
hard, I think. Assuming that the format is "free", and that we don't
have to pay licensing fees or similar...)

No fees at all, it's a free format. And yes, it would be nice to have it
supported by something better (= more user friendly) than emacs ;) The
academic community is just now waking up to the opportunities offered by
Linux.

Post by Dave Malcolm
OK - I just had a look through the DTD structure of TEI and now I'm
scared!

See what I mean? :)

Post by Dave Malcolm
Lots of fragments of DTD information in multiple files. The
good thing is that Conglomerate xds files are quite "sloppy", and it
doesn't really matter if you have elements missing, or extra elements.
It might even be worth redesigning how Conglomerate's xds files are
structured to make it easier to handle TEI...

Keep in mind, though, that usually you don't use the *whole* TEI stuff:
you either specify the parts you need (e.g. TEI.prose and TEI.textcrit
if you're dealing with a prose text and adding a critical apparatus to
it) and go ahead, OR you cook a custom dtd (called "TEI view") which
includes only the elements from the sections you need plus your possible
modifications (you can rename elements, f.i.). TEI Lite is an example of
a possible TEI view with all the most commonly used elements.

So producing an xds file with *all* of possible TEI elements, while
surely worthwhile, would probably be a tedious task AND overkill for 99%
of the users. It would make sense try to mimic the TEI mechanism and
manage to "merge" several xds as needed, I wonder if that would be
possible. It would also be nice to have some sort of GUI tool to edit
Display Specs, with property windows, drag'n'drop and the like, but I'll
stop dreaming now :)

Post by Dave Malcolm

Post by Roberto Rosselli Del Turco
I managed to load the teixlite.dtd, though, and save a display
specification for Conglomerate. Same for the Digital Scriptorium dtd,
which is based on a single dtd file very similar to the TEI Lite one.
I still haven't had the time to refine the resulting .xds files, if you
(Walter, I mean :) are interested we can work together on it,
subdividing work and checking each other's files.

Please can you post your xds files to this list! It'd be good to add
them to CVS, and into the tarballs. That way we can have TEI support
for everyone, from install. Whenever you find an element that isn't
supported, just add it to the xds file and post a patch to the list.

I'm going to add it to the bug entry, unless you want it on the list.
Bit please don't use it yet for the tarballs, I'd like to fine tune it a
bit (at the moment it's just the dtd dump).

Post by Dave Malcolm
This would probably be a single "tei.xds" file, or maybe a "tei.xds.in"
file so that we can support translations of the element names.
Are there any sample instance documents that we could freely
redistribute in the "examples" subfolder? This is much nicer from a
testing point-of-view.

I believe there are some on the TEI site. If not I can try to find
something appropriate.

BTW, TEI dtds and stylesheet are available as RPM packets on Mandrake
Linux contrib repositories.

Ciao

[Dave Malcolm]

Post by Roberto Rosselli Del Turco

Post by Dave Malcolm
In theory, perhaps we could have multiple xds files, one for each DTD,
with some kind of entity referencing thing going on to reuse the common
features.
(I really need to take a good look at TEI before commenting further I
think - looks like it'd be a nice format to add, and wouldn't be too
hard, I think. Assuming that the format is "free", and that we don't
have to pay licensing fees or similar...)

No fees at all, it's a free format. And yes, it would be nice to have it
supported by something better (= more user friendly) than emacs ;) The
academic community is just now waking up to the opportunities offered by
Linux.

Well, I'm now keen to add TEI to the list of XML formats that
Conglomerate will try to support.

Post by Roberto Rosselli Del Turco

Post by Dave Malcolm
OK - I just had a look through the DTD structure of TEI and now I'm
scared!

See what I mean? :)

Post by Dave Malcolm
Lots of fragments of DTD information in multiple files. The
good thing is that Conglomerate xds files are quite "sloppy", and it
doesn't really matter if you have elements missing, or extra elements.
It might even be worth redesigning how Conglomerate's xds files are
structured to make it easier to handle TEI...

you either specify the parts you need (e.g. TEI.prose and TEI.textcrit
if you're dealing with a prose text and adding a critical apparatus to
it) and go ahead, OR you cook a custom dtd (called "TEI view") which
includes only the elements from the sections you need plus your possible
modifications (you can rename elements, f.i.). TEI Lite is an example of
a possible TEI view with all the most commonly used elements.
So producing an xds file with *all* of possible TEI elements, while
surely worthwhile, would probably be a tedious task AND overkill for 99%

As I said, it doesn't usually matter if your dispspec contains more
elements than are in the DTD. You can have a dispspec that contains
simply the union of all possible elements. The trouble is that at the
moment, each dispspec is only expected to associate with a single DTD.
There isn't a mechanism yet for dealing with this kind of "family of
DTDs" approach. We could use entities to reuse fragments of xds file
and have a big family of xds files, perhaps.

Need to think this through, and consider what to do with similar
approaches. For example, this feels similar to the problem of when
someone wants to edit instances of a customised version of the DocBook
DTD.

Perhaps we should focus on TEI Lite for the moment?

Post by Roberto Rosselli Del Turco
of the users. It would make sense try to mimic the TEI mechanism and
manage to "merge" several xds as needed, I wonder if that would be
possible. It would also be nice to have some sort of GUI tool to edit
Display Specs, with property windows, drag'n'drop and the like, but I'll
stop dreaming now :)

Please file an enhancement request in Bugzilla! (I'm serious)

Post by Roberto Rosselli Del Turco

Post by Dave Malcolm

Post by Roberto Rosselli Del Turco
I managed to load the teixlite.dtd, though, and save a display
specification for Conglomerate. Same for the Digital Scriptorium dtd,
which is based on a single dtd file very similar to the TEI Lite one.
I still haven't had the time to refine the resulting .xds files, if you
(Walter, I mean :) are interested we can work together on it,
subdividing work and checking each other's files.

Please can you post your xds files to this list! It'd be good to add
them to CVS, and into the tarballs. That way we can have TEI support
for everyone, from install. Whenever you find an element that isn't
supported, just add it to the xds file and post a patch to the list.

I'm going to add it to the bug entry, unless you want it on the list.
Bit please don't use it yet for the tarballs, I'd like to fine tune it a
bit (at the moment it's just the dtd dump).

I'm trying out your xds file; I'm ready to add it to CVS (which will put
it in tarballs).

Looks like Conglomerate didn't do a great job of generating the xds
file, but it's a start. Some issues to look at:
- sort out the external-document-model element so that it knows about
the DTD
- fix the name and description in the metadata
- possibly remove the xml:lang attributes from the <name> elements
- possibly remove all the <name> elements, or fix them so they make
sense.
- use plugins where appropriate
- add icons
- etc

Let the list know when you've got a new xds file; I'm keen to add it.

Thanks!

Dave

Post by Roberto Rosselli Del Turco

Post by Dave Malcolm
This would probably be a single "tei.xds" file, or maybe a "tei.xds.in"
file so that we can support translations of the element names.
Are there any sample instance documents that we could freely
redistribute in the "examples" subfolder? This is much nicer from a
testing point-of-view.

I believe there are some on the TEI site. If not I can try to find
something appropriate.
BTW, TEI dtds and stylesheet are available as RPM packets on Mandrake
Linux contrib repositories.
Ciao

[Roberto Rosselli Del Turco]

Post by Dave Malcolm
As I said, it doesn't usually matter if your dispspec contains more
elements than are in the DTD. You can have a dispspec that contains
simply the union of all possible elements. The trouble is that at the
moment, each dispspec is only expected to associate with a single DTD.
There isn't a mechanism yet for dealing with this kind of "family of
DTDs" approach. We could use entities to reuse fragments of xds file
and have a big family of xds files, perhaps.

I was thinking about something like that, but of course you're the one
knowing what's possible.

Post by Dave Malcolm
Need to think this through, and consider what to do with similar
approaches. For example, this feels similar to the problem of when
someone wants to edit instances of a customised version of the DocBook
DTD.
Perhaps we should focus on TEI Lite for the moment?

Yes, my (implicit) conclusion too.

Post by Dave Malcolm

Post by Roberto Rosselli Del Turco
of the users. It would make sense try to mimic the TEI mechanism and
manage to "merge" several xds as needed, I wonder if that would be
possible. It would also be nice to have some sort of GUI tool to edit
Display Specs, with property windows, drag'n'drop and the like, but I'll
stop dreaming now :)

Please file an enhancement request in Bugzilla! (I'm serious)

OK, will do during this week. I've also got the .pot file to translate
into Italian ;)

Post by Dave Malcolm
I'm trying out your xds file; I'm ready to add it to CVS (which will put
it in tarballs).
Looks like Conglomerate didn't do a great job of generating the xds
- sort out the external-document-model element so that it knows about
the DTD

Hmm, can you elaborate on this? I'm not sure I understand what you mean.

Post by Dave Malcolm
- fix the name and description in the metadata

OK.

Post by Dave Malcolm
- possibly remove the xml:lang attributes from the <name> elements

xml:lang="C" looks pretty useless to me.

Post by Dave Malcolm
- possibly remove all the <name> elements, or fix them so they make
sense.

I have prepared a similar list for the gedit tag list plugin: I usually
expanded where possible (e.g. Paragraph for the <p> element) and left
unmodified those that make sense on their own (e.g. Imprint).

Post by Dave Malcolm
- use plugins where appropriate

Hmm, what plugins are available? what do they do? where can I read about
those?

Post by Dave Malcolm
- add icons

OK.

Post by Dave Malcolm
Let the list know when you've got a new xds file; I'm keen to add it.

OK!

Post by Dave Malcolm
Thanks!

You're welcome :)

Ciao

[Dave Malcolm]

Post by Roberto Rosselli Del Turco

Post by Dave Malcolm
As I said, it doesn't usually matter if your dispspec contains more
elements than are in the DTD. You can have a dispspec that contains
simply the union of all possible elements. The trouble is that at the
moment, each dispspec is only expected to associate with a single DTD.
There isn't a mechanism yet for dealing with this kind of "family of
DTDs" approach. We could use entities to reuse fragments of xds file
and have a big family of xds files, perhaps.

I was thinking about something like that, but of course you're the one
knowing what's possible.

Post by Dave Malcolm
Need to think this through, and consider what to do with similar
approaches. For example, this feels similar to the problem of when
someone wants to edit instances of a customised version of the DocBook
DTD.
Perhaps we should focus on TEI Lite for the moment?

Yes, my (implicit) conclusion too.

OK. So we'll probably have a single file called "teixlite.xds" in
Conglomerate's examples subfolder (to match the dtd filename)?

[snip]

Post by Roberto Rosselli Del Turco

Post by Dave Malcolm
Looks like Conglomerate didn't do a great job of generating the xds
- sort out the external-document-model element so that it knows about
the DTD

Hmm, can you elaborate on this? I'm not sure I understand what you mean.

The public-id and system-id attributes should be set to give the
information normally supplied in a DOCTYPE declaration. By way of
reference, the equivalent tag in the docbook xds file looks like this:
<external-document-model type="dtd" public-id="-//OASIS//DTD DocBook XML
V4.1.2//EN"
system-id="http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd"/>

This can be used by Conglomerate to spot when a particular DTD is in
use; also if you go to File->Properties there's a GUI for adding DOCTYPE
declarations to a document which uses this part of the dispspec.

It's best to supply both a public ID that's the formal public ID, and a
system ID that's a URI, rather than a reference to a locally installed
file. Hopefully the user should have the file in their catalog so that
libxml can find the local copy...

Post by Roberto Rosselli Del Turco

Post by Dave Malcolm
- fix the name and description in the metadata

OK.

Post by Dave Malcolm
- possibly remove the xml:lang attributes from the <name> elements

xml:lang="C" looks pretty useless to me.

Yes, it probably should be removed (simple search & replace)

Post by Roberto Rosselli Del Turco

Post by Dave Malcolm
- possibly remove all the <name> elements, or fix them so they make
sense.

I have prepared a similar list for the gedit tag list plugin: I usually
expanded where possible (e.g. Paragraph for the <p> element) and left
unmodified those that make sense on their own (e.g. Imprint).

Excellent.

Post by Roberto Rosselli Del Turco

Post by Dave Malcolm
- use plugins where appropriate

Hmm, what plugins are available? what do they do? where can I read about
those?

No documentation at the moment, so I'll write some here, once I've sent
this email I'm going to put this into the FAQ:

Custom Rendering of an XML element:
-----------------------------------
Most of the element types are either "structural" or "span". It's
possible to supply a custom type using the plugin system. This will
affect how elements of that type are displayed in Conglomerate's main
editor widget.

Currently existing IDs:
-----------------------
"paragraph": This is used by the DocBook <para> element and should be
used by any other document type to represent a typical paragraph-level
element. Currently it renders itself as a dashed rectangle surrounding
the element's content. We might add a "pilcrow" symbol (a little q) as
an extra refinement at some point.

"admonition": This is used by DocBook's admonition elements: <note>,
<tip>, <caution> etc. It renders itself as an icon on the left, with
the element's content presented in an indented form to the right. It
could be used by any other element that would be well-presented as a
icon labelling the content. The key-value pair "icon" should be used to
specify which icon to use for each particular element.

"listitem": This is used by DocBook's <listitem> element. It renders
itself as a textual label, with the content indented on the right-hand
side. Currently the code has hardcoded logic that generates the label
according to DocBook's semantics; it looks to see if its inside an
<orderedlist> or an <itemizedlist>, and what position it occupies in
that list etc to generate either a bullet or a numbering. This could be
generalised if people want to reuse the code for other DTDs.

Setting this up inside the xds file:
------------------------------------
The xds file should use the value "plugin" for the element's "type"
attribute. The element will need to have an additional attribute
"plugin-id" (I hope to rename this to "service-id" before the 0.8.0
release), which should have a value corresponding to the string ID that
the service is registered with inside the plugin.

This affects how elements of that type are rendered in the main editor
widget. For other purposes (such as XML Source cleanup, handling the
Overview sidebar, etc), such elements are, in general, treated like
structural elements (as opposed to span ones).

Some plugin element types need additional information in the xds file;
this is done by having a <key-value-list> element below the <element>
element; the <key-value-list> should contain <key-value-pair> elements.
Each <key-value-pair> element should contain a "key" and "value"
attribute. See DocBook's <caution> element for an example.

Customising the Property dialog for an XML element:
---------------------------------------------------
Another thing you can do to improve support for a DTD is to create a
plugin node property dialog. To do this, add a <property-dialog>
element inside the main <element>, with a "plugin-id" attribute giving
the registered ID of the code providing the GtkWidget for elements of
that type (again, this will probably become "service-id" before the
0.8.0 release).

For example for the DocBook <orderedlist> element; the xds file gives an
ID of "docbook-orderedlist-properties". This is hooked up in the source
code in src/plugin-docbook.c to a routine (the C function
"docbook_orderedlist_properties_factory_method") which loads a GUI from
a Glade file, and uses a set of utility functions that bind the widgets
in the glade file to attributes of the XML element. For example, the
radio buttons are linked to the various valid values of the "numeration"
attribute.

Post by Roberto Rosselli Del Turco

Post by Dave Malcolm
- add icons

OK.

Post by Dave Malcolm
Let the list know when you've got a new xds file; I'm keen to add it.

OK!

Don't feel like you have to sort out all of the above before submitting
something. As soon as you've got something that works on some test
documents it's probably worth posting it so we can add to CVS (and to
the tarballs). Refinements can happen at a later stage.

Post by Roberto Rosselli Del Turco

Post by Dave Malcolm
Thanks!

You're welcome :)
Ciao

[Dave Malcolm]

Post by Dave Malcolm
No documentation at the moment, so I'll write some here, once I've sent

I've added this all to the doc/C/faq.xml in CVS; this should appear on
the website next time it gets updated.

I've also made the changes of "plugin-id" to "service-id" in the code,
the xds files, and the DTD for xds files.

Post by Dave Malcolm
-----------------------------------
Most of the element types are either "structural" or "span". It's
possible to supply a custom type using the plugin system. This will
affect how elements of that type are displayed in Conglomerate's main
editor widget.
-----------------------
"paragraph": This is used by the DocBook <para> element and should be
used by any other document type to represent a typical paragraph-level
element. Currently it renders itself as a dashed rectangle surrounding
the element's content. We might add a "pilcrow" symbol (a little q) as
an extra refinement at some point.
"admonition": This is used by DocBook's admonition elements: <note>,
<tip>, <caution> etc. It renders itself as an icon on the left, with
the element's content presented in an indented form to the right. It
could be used by any other element that would be well-presented as a
icon labelling the content. The key-value pair "icon" should be used to
specify which icon to use for each particular element.
"listitem": This is used by DocBook's <listitem> element. It renders
itself as a textual label, with the content indented on the right-hand
side. Currently the code has hardcoded logic that generates the label
according to DocBook's semantics; it looks to see if its inside an
<orderedlist> or an <itemizedlist>, and what position it occupies in
that list etc to generate either a bullet or a numbering. This could be
generalised if people want to reuse the code for other DTDs.
------------------------------------
The xds file should use the value "plugin" for the element's "type"
attribute. The element will need to have an additional attribute
"plugin-id" (I hope to rename this to "service-id" before the 0.8.0
release), which should have a value corresponding to the string ID that
the service is registered with inside the plugin.
This affects how elements of that type are rendered in the main editor
widget. For other purposes (such as XML Source cleanup, handling the
Overview sidebar, etc), such elements are, in general, treated like
structural elements (as opposed to span ones).
Some plugin element types need additional information in the xds file;
this is done by having a <key-value-list> element below the <element>
element; the <key-value-list> should contain <key-value-pair> elements.
Each <key-value-pair> element should contain a "key" and "value"
attribute. See DocBook's <caution> element for an example.
---------------------------------------------------
Another thing you can do to improve support for a DTD is to create a
plugin node property dialog. To do this, add a <property-dialog>
element inside the main <element>, with a "plugin-id" attribute giving
the registered ID of the code providing the GtkWidget for elements of
that type (again, this will probably become "service-id" before the
0.8.0 release).
For example for the DocBook <orderedlist> element; the xds file gives an
ID of "docbook-orderedlist-properties". This is hooked up in the source
code in src/plugin-docbook.c to a routine (the C function
"docbook_orderedlist_properties_factory_method") which loads a GUI from
a Glade file, and uses a set of utility functions that bind the widgets
in the glade file to attributes of the XML element. For example, the
radio buttons are linked to the various valid values of the "numeration"
attribute.

Post by Roberto Rosselli Del Turco

Post by Dave Malcolm
- add icons

OK.

Post by Dave Malcolm
Let the list know when you've got a new xds file; I'm keen to add it.

OK!

Don't feel like you have to sort out all of the above before submitting
something. As soon as you've got something that works on some test
documents it's probably worth posting it so we can add to CVS (and to
the tarballs). Refinements can happen at a later stage.

Post by Roberto Rosselli Del Turco

Post by Dave Malcolm
Thanks!

You're welcome :)
Ciao

_______________________________________________
Conglomerate mailing list
http://lists.copyleft.no/mailman/listinfo/conglomerate

[Roberto Rosselli Del Turco]

Post by Dave Malcolm

Post by Roberto Rosselli Del Turco

Post by Dave Malcolm
Perhaps we should focus on TEI Lite for the moment?

Yes, my (implicit) conclusion too.

OK. So we'll probably have a single file called "teixlite.xds" in
Conglomerate's examples subfolder (to match the dtd filename)?

Hmm, why the "examples" subfolder and not the dispspecs one?

One more thought which occurred to me while thinking about TEI/TEI Lite:
as I hinted, very often you don't use TEI (Lite) but a personal view of
the TEI dtd which can have (and normally has) a completely different
name. This means that, even if the dtd is a subset of the TEI superset,
you can't have it recognized by Conglomerate because the dtd is a
different and differently named file; I suppose something similar may
happen with customized versions of docbook. So, why not allowing the
user to *choose* a dispspec for his document, if it can't automatically
be assigned by Conge?

Post by Dave Malcolm

Post by Roberto Rosselli Del Turco

Post by Dave Malcolm
- possibly remove the xml:lang attributes from the <name> elements

xml:lang="C" looks pretty useless to me.

Yes, it probably should be removed (simple search & replace)

How about the whitespace="normalize" attribute?

Post by Dave Malcolm
Don't feel like you have to sort out all of the above before submitting
something. As soon as you've got something that works on some test
documents it's probably worth posting it so we can add to CVS (and to
the tarballs). Refinements can happen at a later stage.

OK, thanks for all the info.

Ciao

[Dave Malcolm]

Post by Roberto Rosselli Del Turco

Post by Dave Malcolm

Post by Roberto Rosselli Del Turco

Post by Dave Malcolm
Perhaps we should focus on TEI Lite for the moment?

Yes, my (implicit) conclusion too.

OK. So we'll probably have a single file called "teixlite.xds" in
Conglomerate's examples subfolder (to match the dtd filename)?

Hmm, why the "examples" subfolder and not the dispspecs one?

There isn't a dispspecs folder, due to a historical accident. Probably
should get fixed before 0.8.0 (Added as bug #133406).

Are you happy for me to add the latest bugzilla attachment to CVS (and
into tarballs) as "teixlite.xds"?

Post by Roberto Rosselli Del Turco
as I hinted, very often you don't use TEI (Lite) but a personal view of
the TEI dtd which can have (and normally has) a completely different
name. This means that, even if the dtd is a subset of the TEI superset,
you can't have it recognized by Conglomerate because the dtd is a
different and differently named file; I suppose something similar may
happen with customized versions of docbook. So, why not allowing the
user to *choose* a dispspec for his document, if it can't automatically
be assigned by Conge?

I was convinced there was already a bug about this, but couldn't find
it; so I've added it as bug #133405.

Post by Roberto Rosselli Del Turco

Post by Dave Malcolm

Post by Roberto Rosselli Del Turco

Post by Dave Malcolm
- possibly remove the xml:lang attributes from the <name> elements

xml:lang="C" looks pretty useless to me.

Yes, it probably should be removed (simple search & replace)

How about the whitespace="normalize" attribute?

Get rid of it! This is the default value. (The xds output is too
verbose; I've filed bug #133401 about this)

Post by Roberto Rosselli Del Turco

Post by Dave Malcolm
Don't feel like you have to sort out all of the above before submitting
something. As soon as you've got something that works on some test
documents it's probably worth posting it so we can add to CVS (and to
the tarballs). Refinements can happen at a later stage.

OK, thanks for all the info.
Ciao

[Roberto Rosselli Del Turco]

Post by Dave Malcolm

Post by Roberto Rosselli Del Turco
Hmm, why the "examples" subfolder and not the dispspecs one?

There isn't a dispspecs folder, due to a historical accident. Probably
should get fixed before 0.8.0 (Added as bug #133406).

Funny, I'd swear I have this folder on my disk:
/usr/local/share/conglomerate/dispspecs/ ;) But I'm curious about the
"historical accident", this reminds me of the weird fate of the
diskdoctor program under Amiga OS 1.3/2.0 :))))

Post by Dave Malcolm
Are you happy for me to add the latest bugzilla attachment to CVS (and
into tarballs) as "teixlite.xds"?

Go ahead, should be usable now. Perhaps Walter can have a look at it and
tell us his impressions.

Post by Dave Malcolm

Post by Roberto Rosselli Del Turco
happen with customized versions of docbook. So, why not allowing the
user to *choose* a dispspec for his document, if it can't automatically
be assigned by Conge?

I was convinced there was already a bug about this, but couldn't find
it; so I've added it as bug #133405.

[...]

Post by Dave Malcolm

Post by Roberto Rosselli Del Turco
How about the whitespace="normalize" attribute?

Get rid of it! This is the default value. (The xds output is too
verbose; I've filed bug #133401 about this)

Man, you've been busy filing bugs all day long :)

Ciao

[Dave Malcolm]

Post by Roberto Rosselli Del Turco

Post by Dave Malcolm

Post by Roberto Rosselli Del Turco
Hmm, why the "examples" subfolder and not the dispspecs one?

There isn't a dispspecs folder, due to a historical accident. Probably
should get fixed before 0.8.0 (Added as bug #133406).

/usr/local/share/conglomerate/dispspecs/ ;) But I'm curious about the
"historical accident", this reminds me of the weird fate of the
diskdoctor program under Amiga OS 1.3/2.0 :))))

The dispspecs are installed to a "dispspecs" folder; it's just that
within the tarball and CVS they live in the "examples" folder. Don't
worry about it, we'll fix it at some point :-)

Post by Roberto Rosselli Del Turco

Post by Dave Malcolm
Are you happy for me to add the latest bugzilla attachment to CVS (and
into tarballs) as "teixlite.xds"?

Go ahead, should be usable now. Perhaps Walter can have a look at it and
tell us his impressions.

I've added the attachment you added today (id=24047) to CVS in
examples/teixlite.xds (with corresponding changes to the Makefile.am).

I had to escape a stray tag on line 505 to make it work (we need some
kind of allowed mixed-content for the descriptive text).

I'm having a few problems with the DTD; does this work for you?

Post by Roberto Rosselli Del Turco

Post by Dave Malcolm

Post by Roberto Rosselli Del Turco
happen with customized versions of docbook. So, why not allowing the
user to *choose* a dispspec for his document, if it can't automatically
be assigned by Conge?

I was convinced there was already a bug about this, but couldn't find
it; so I've added it as bug #133405.

[...]

Post by Dave Malcolm

Post by Roberto Rosselli Del Turco
How about the whitespace="normalize" attribute?

Get rid of it! This is the default value. (The xds output is too
verbose; I've filed bug #133401 about this)

Man, you've been busy filing bugs all day long :)

(and trying to fix them...)

Post by Roberto Rosselli Del Turco
Ciao

[Roberto Rosselli Del Turco]

Post by Dave Malcolm
I'm having a few problems with the DTD; does this work for you?

The dtd itself (i.e. loading documents based on teixlite using Conge)?
Can't try at the moment, will do during the week-end.

Ciao

[Roberto Rosselli Del Turco]

Post by Dave Malcolm
I'm having a few problems with the DTD; does this work for you?

I don't have teixlite documents that I produced, so I tried with what I
found lying on my hd. First I tried to load the teixlite doc itself, and
Conglomerate failed with these errors (each message was repeated several
times):

** (conglomerate:3660): WARNING **: unable to convert attribute end
index 2

** (conglomerate:3660): WARNING **: unable to convert attribute end
index 3

** (conglomerate:3660): WARNING **: unable to convert attribute end
index 4

** (conglomerate:3660): WARNING **: unable to convert attribute end
index 619

** (conglomerate:3660): WARNING **: unable to convert attribute end
index 224

** (conglomerate:3660): CRITICAL **: file cong-text-cache.c: line 168
(cong_text_cache_set_input_attributes): assertion `attr_list' failed

Then I tried with another file, and this one was loaded successfully,
even if the CRITICAL error was output once. Is this of help?

BTW, still haven't recompiled conge with the tei lite dispspec, so can't
check how well it works yet. Will do asap.

Ciao

[Dave Malcolm]

Post by Roberto Rosselli Del Turco

Post by Dave Malcolm
I'm having a few problems with the DTD; does this work for you?

I don't have teixlite documents that I produced, so I tried with what I
found lying on my hd. First I tried to load the teixlite doc itself, and
Conglomerate failed with these errors (each message was repeated several
** (conglomerate:3660): WARNING **: unable to convert attribute end
index 2
** (conglomerate:3660): WARNING **: unable to convert attribute end
index 3
** (conglomerate:3660): WARNING **: unable to convert attribute end
index 4
** (conglomerate:3660): WARNING **: unable to convert attribute end
index 619
** (conglomerate:3660): WARNING **: unable to convert attribute end
index 224

I see the above warnings quite a lot; I believe it's an off-by-one error
somewhere in the code which normalizes whitespace. Doesn't seem to
cause problems, and I hope to track it down at some point.

Post by Roberto Rosselli Del Turco
** (conglomerate:3660): CRITICAL **: file cong-text-cache.c: line 168
(cong_text_cache_set_input_attributes): assertion `attr_list' failed

Does this happen on loading the file, or when editing it? (I believe
this function only gets called when highlighting text)

Is it fatal? Please post a stack trace if possible.

Post by Roberto Rosselli Del Turco
Then I tried with another file, and this one was loaded successfully,
even if the CRITICAL error was output once. Is this of help?
BTW, still haven't recompiled conge with the tei lite dispspec, so can't
check how well it works yet. Will do asap.
Ciao

[Roberto Rosselli Del Turco]

Post by Dave Malcolm

Post by Roberto Rosselli Del Turco
** (conglomerate:3660): CRITICAL **: file cong-text-cache.c: line 168
(cong_text_cache_set_input_attributes): assertion `attr_list' failed

Does this happen on loading the file, or when editing it? (I believe
this function only gets called when highlighting text)

When loading the file, conge segfaults before it has a chance to show
anything.

Post by Dave Malcolm
Is it fatal? Please post a stack trace if possible.

Yes. Does the "(no debugging symbols found)" mean that I have to
configure with --debug on (or something like that) to have more
information? here's the trace:

Program received signal SIGSEGV, Segmentation fault.
0x0807f087 in cong_editor_line_fragments_get_area_list ()
(gdb) bt
#0 0x0807f087 in cong_editor_line_fragments_get_area_list ()
#1 0x0807f91c in cong_editor_node_generate_line_areas_recursive ()
#2 0x0807a7a2 in cong_editor_area_flow_holder_inlines_get_final_node ()
#3 0x0807ef5a in cong_editor_child_policy_inline_new ()
#4 0x0807eadc in cong_editor_child_policy_insert_areas_for_node ()
#5 0x08085069 in cong_editor_widget3_node_should_have_editor_node ()
#6 0x08084efa in cong_editor_widget3_get_preedit_data ()
#7 0x08084f19 in cong_editor_widget3_get_preedit_data ()
#8 0x08084f19 in cong_editor_widget3_get_preedit_data ()
#9 0x08084f19 in cong_editor_widget3_get_preedit_data ()
#10 0x08084f19 in cong_editor_widget3_get_preedit_data ()
#11 0x08084f19 in cong_editor_widget3_get_preedit_data ()
#12 0x08084f19 in cong_editor_widget3_get_preedit_data ()
#13 0x08084f19 in cong_editor_widget3_get_preedit_data ()
#14 0x08084f19 in cong_editor_widget3_get_preedit_data ()
#15 0x08084fa4 in cong_editor_widget3_get_preedit_data ()
#16 0x08083218 in cong_editor_widget3_construct ()
#17 0x08083307 in cong_editor_widget3_new ()
#18 0x0809ad67 in cong_primary_window_add_doc ()
#19 0x0809b2bb in cong_primary_window_new ()
#20 0x0808934d in open_document_do ()
#21 0x0808946c in open_document ()
#22 0x080894c7 in toolbar_callback_open ()

Ciao

[Dave Malcolm]

Post by Roberto Rosselli Del Turco

Post by Dave Malcolm

Post by Roberto Rosselli Del Turco
** (conglomerate:3660): CRITICAL **: file cong-text-cache.c: line 168
(cong_text_cache_set_input_attributes): assertion `attr_list' failed

Does this happen on loading the file, or when editing it? (I believe
this function only gets called when highlighting text)

When loading the file, conge segfaults before it has a chance to show
anything.

Post by Dave Malcolm
Is it fatal? Please post a stack trace if possible.

Yes. Does the "(no debugging symbols found)" mean that I have to
configure with --debug on (or something like that) to have more
Program received signal SIGSEGV, Segmentation fault.
0x0807f087 in cong_editor_line_fragments_get_area_list ()
(gdb) bt
#0 0x0807f087 in cong_editor_line_fragments_get_area_list ()
#1 0x0807f91c in cong_editor_node_generate_line_areas_recursive ()
#2 0x0807a7a2 in cong_editor_area_flow_holder_inlines_get_final_node ()
#3 0x0807ef5a in cong_editor_child_policy_inline_new ()
#4 0x0807eadc in cong_editor_child_policy_insert_areas_for_node ()
#5 0x08085069 in cong_editor_widget3_node_should_have_editor_node ()
#6 0x08084efa in cong_editor_widget3_get_preedit_data ()
#7 0x08084f19 in cong_editor_widget3_get_preedit_data ()
#8 0x08084f19 in cong_editor_widget3_get_preedit_data ()
#9 0x08084f19 in cong_editor_widget3_get_preedit_data ()
#10 0x08084f19 in cong_editor_widget3_get_preedit_data ()
#11 0x08084f19 in cong_editor_widget3_get_preedit_data ()
#12 0x08084f19 in cong_editor_widget3_get_preedit_data ()
#13 0x08084f19 in cong_editor_widget3_get_preedit_data ()
#14 0x08084f19 in cong_editor_widget3_get_preedit_data ()
#15 0x08084fa4 in cong_editor_widget3_get_preedit_data ()
#16 0x08083218 in cong_editor_widget3_construct ()
#17 0x08083307 in cong_editor_widget3_new ()
#18 0x0809ad67 in cong_primary_window_add_doc ()
#19 0x0809b2bb in cong_primary_window_new ()
#20 0x0808934d in open_document_do ()
#21 0x0808946c in open_document ()
#22 0x080894c7 in toolbar_callback_open ()

That's a well known bug, there are about 20 duplicates in Bugzilla, and
it's a hard problem to fix (the WidgetPlayground branch in CVS is my
work towards this, and should let you load, but not edit the file)

The problem is that a structural tag has been found inside a span tag,
and the code doesn't know how to deal with it.

You may be able to work around the problem by hacking the dispspec, or
by hacking the file.

Post by Roberto Rosselli Del Turco
Ciao

[Geert Stappers]

<snip/>

Post by Roberto Rosselli Del Turco

Post by Dave Malcolm
Are you happy for me to add the latest bugzilla attachment to CVS (and
into tarballs) as "teixlite.xds"?

Go ahead, should be usable now. Perhaps Walter can have a look at it and
tell us his impressions.

There is a tarball

http://www.stappers.nl/gst/temporary/conglomerate-0.7.12pre1.tar.gz


As allways feedback is welcome.


Cheers
Geert Stappers

[Walter H. van Holst]

Post by Geert Stappers
There is a tarball
http://www.stappers.nl/gst/temporary/conglomerate-0.7.12pre1.tar.gz
As allways feedback is welcome.

Ah, cool, I'll try to look into it next weekend.

Regards,

Walter

[Roberto Rosselli Del Turco]

Hi Dave,
I followed your instructions but the new dispspec file is not present in
/usr/local/share/conglomerate/dispspecs after make - make install. This
dispspec_DATA = \
cnxml.xds \
dispspec-template.xds \
readme.xds \
relax-ng.xds \
website-layout.xds \
website-webpage.xds \
xsl.xds \
teixlite.xds \
$(dispspec_in_files:.xds.in=.xds)

This looks correct to me; I've done the same to the Makefile.am in CVS
and it works for me. Is the Makefile being regenerated? Is the xds
file there in the examples directory of the source tree?

Don't know about the "regeneration" thing (sorry :) but the file is most
definitely there.

I even tried a make clean before make, but to no avail. What am I doing
wrong?

Go to the "examples" folder and do a "make" and then a "make install" on
just that folder and have a look at the output; hopefully you'll spot an
error; otherwise post the output to this list so that we can check it's
sane.

Well, there isn't much output: make: Nothing to be done for `all'.

(In case you didn't see the long email I sent about namespaces, be
warned that in CVS I've changed the dispspec DTD and the loaders, and
the CVS version of the xds files (including the teixlite.xds file) have
changed quite a lot)

That shouldn't be a problem, as I'm still using the 0.7.11 original
tarball. But now that I think of it you said you modified the file I
attached to the bug report somehow ...

Ciao

[Dave Malcolm]

Post by Roberto Rosselli Del Turco

Hi Dave,
I followed your instructions but the new dispspec file is not present in
/usr/local/share/conglomerate/dispspecs after make - make install. This
dispspec_DATA = \
cnxml.xds \
dispspec-template.xds \
readme.xds \
relax-ng.xds \
website-layout.xds \
website-webpage.xds \
xsl.xds \
teixlite.xds \
$(dispspec_in_files:.xds.in=.xds)

This looks correct to me; I've done the same to the Makefile.am in CVS
and it works for me. Is the Makefile being regenerated? Is the xds
file there in the examples directory of the source tree?

Don't know about the "regeneration" thing (sorry :) but the file is most
definitely there.

Aha - you're building from a tarball, not from CVS - that might be it.
Try rerunning the "configure" script.

Post by Roberto Rosselli Del Turco

I even tried a make clean before make, but to no avail. What am I doing
wrong?

Go to the "examples" folder and do a "make" and then a "make install" on
just that folder and have a look at the output; hopefully you'll spot an
error; otherwise post the output to this list so that we can check it's
sane.

Well, there isn't much output: make: Nothing to be done for `all'.

"make install" ought to have some output, I believe it always copies the
files even if they haven't changed. So if this isn't outputting
anything there's a problem.

Post by Roberto Rosselli Del Turco

(In case you didn't see the long email I sent about namespaces, be
warned that in CVS I've changed the dispspec DTD and the loaders, and
the CVS version of the xds files (including the teixlite.xds file) have
changed quite a lot)

That shouldn't be a problem, as I'm still using the 0.7.11 original
tarball. But now that I think of it you said you modified the file I
attached to the bug report somehow ...
Ciao