Discussion:
[Conglomerate] Adding dispspecs
Roberto Rosselli Del Turco
2004-10-23 10:12:52 UTC
Permalink
Hi all,
while playing with different dispspecs and the latest 12.pre
Conglomerate, I noticed that if I add a dispspec in the appropriate
directory, Conge goes and try to load it when loading a suitable
document. Unfortunately, the few documents I tried to load crashed
costantly: is it because Conglomerate needs to be compiled with the
dispspec name in the makefile? It would be nice to be able to modify
current dispspecs, then drop the modified versions in the dispspec
directory and have them work automagically; especially with complex DTDs
like TEI, where, as I hinted in the past, you can have lots of custom
subset-DTDs base on the main one.

Ciao
--
Roberto Rosselli Del Turco roberto.rossellidelturco at unito.it
Dipartimento di Scienze rosselli at ling.unipi.it
del Linguaggio Then spoke the thunder DA
Universita' di Torino Datta: what have we given? (TSE)

Hige sceal the heardra, heorte the cenre,
mod sceal the mare, the ure maegen litlath. (Maldon 312-3)
Geert Stappers
2004-10-23 10:12:52 UTC
Permalink
Post by Roberto Rosselli Del Turco
Hi all,
while playing with different dispspecs and the latest 12.pre
Conglomerate, I noticed that if I add a dispspec in the appropriate
directory, Conge goes and try to load it when loading a suitable
document. Unfortunately, the few documents I tried to load crashed
costantly: is it because Conglomerate needs to be compiled with the
dispspec name in the makefile? It would be nice to be able to modify
current dispspecs, then drop the modified versions in the dispspec
directory and have them work automagically; especially with complex DTDs
like TEI, where, as I hinted in the past, you can have lots of custom
subset-DTDs base on the main one.
AFAIK Conglomerate loads the XDS files only during startup.

IIRC there is _in_ conge a display spec file edit function,
that can reload the fresh edited dot xds.
Post by Roberto Rosselli Del Turco
Ciao
--
Roberto Rosselli Del Turco roberto.rossellidelturco at unito.it
Geert Stappers
Roberto Rosselli Del Turco
2004-10-23 10:12:52 UTC
Permalink
Post by Geert Stappers
Post by Roberto Rosselli Del Turco
Hi all,
while playing with different dispspecs and the latest 12.pre
Conglomerate, I noticed that if I add a dispspec in the appropriate
directory, Conge goes and try to load it when loading a suitable
document. Unfortunately, the few documents I tried to load crashed
costantly: is it because Conglomerate needs to be compiled with the
dispspec name in the makefile? It would be nice to be able to modify
current dispspecs, then drop the modified versions in the dispspec
directory and have them work automagically; especially with complex DTDs
like TEI, where, as I hinted in the past, you can have lots of custom
subset-DTDs base on the main one.
AFAIK Conglomerate loads the XDS files only during startup.
Indeed, this is the output on the command line:

** Message: Loading xds files from "/home/roby/.conglomerate/dispspecs"

CongDispspecRegistry contains 14 dispspec(s)
ds[0] = "Experimental "cnxml" format"
ds[1] = "Name of this document type"
ds[2] = "Experimental "readme" format"
ds[3] = "RELAX NG"
ds[4] = "Website Layout"
ds[5] = "Webpage"
ds[6] = "XSL stylesheet"
ds[7] = "DocBook"
ds[8] = "Conglomerate Display Specification"
ds[9] = "Apache Documentation DTD v1.2"
ds[10] = ""Kernel Traffic" Newsletter"
ds[11] = "XHTML 1.0 (strict)"
ds[12] = "TEI Lite"
ds[13] = "Digital Scriptorium"

The 13th dispspec (Digital Scriptorium) is the one I added before
launching C.
Post by Geert Stappers
IIRC there is _in_ conge a display spec file edit function,
that can reload the fresh edited dot xds.
Having to restart Conglomerate in case you add a new dispspec doesn't
look particularly cumbersome, provided that dropping it in the
appropriate directory and restarting the program actually means having
the dispspec working. In fact, this is what happens when I try to load a
DS document:

** Message: coverage of TEI Lite = 0,838710
** Message: coverage of Digital Scriptorium = 0,991935

Here Conglomerate identifies the DS dispspec as being the closest one to
the document, then prints these lines

** Message: searching for "paragraph" found "admonition"
** Message: searching for "paragraph" found "listitem"
** Message: searching for "paragraph" found "paragraph"

And dies. For one of my sample documents I also get this:

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

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

I wonder if it's because of some mistakes I could have done in modifying
the TEI lite dispspec to generate the DS one.

Ciao
--
Roberto Rosselli Del Turco roberto.rossellidelturco at unito.it
Dipartimento di Scienze rosselli at ling.unipi.it
del Linguaggio Then spoke the thunder DA
Universita' di Torino Datta: what have we given? (TSE)

Hige sceal the heardra, heorte the cenre,
mod sceal the mare, the ure maegen litlath. (Maldon 312-3)
Geert Stappers
2004-10-23 10:12:52 UTC
Permalink
Post by Roberto Rosselli Del Turco
Post by Geert Stappers
Post by Roberto Rosselli Del Turco
Hi all,
<snip/>
Post by Roberto Rosselli Del Turco
Post by Geert Stappers
Post by Roberto Rosselli Del Turco
It would be nice to be able to modify
current dispspecs, then drop the modified versions in the dispspec
directory and have them work automagically;
<snip/>
Post by Roberto Rosselli Del Turco
Post by Geert Stappers
AFAIK Conglomerate loads the XDS files only during startup.
** Message: Loading xds files from "/home/roby/.conglomerate/dispspecs"
CongDispspecRegistry contains 14 dispspec(s)
ds[0] = "Experimental "cnxml" format"
ds[1] = "Name of this document type"
<snip/>
Post by Roberto Rosselli Del Turco
ds[12] = "TEI Lite"
ds[13] = "Digital Scriptorium"
The 13th dispspec (Digital Scriptorium) is the one I added before
launching C.
launching C-compiler?
launching Conglomerate?
( /me telling that I first didn't understood what you mean with 'C' )
Post by Roberto Rosselli Del Turco
Post by Geert Stappers
IIRC there is _in_ conge a display spec file edit function,
that can reload the fresh edited dot xds.
Having to restart Conglomerate in case you add a new dispspec doesn't
look particularly cumbersome, provided that dropping it in the
appropriate directory and restarting the program actually means having
the dispspec working. In fact, this is what happens when I try to load a
** Message: coverage of TEI Lite = 0,838710
** Message: coverage of Digital Scriptorium = 0,991935
Here Conglomerate identifies the DS dispspec as being the closest one to
the document, then prints these lines
** Message: searching for "paragraph" found "admonition"
** Message: searching for "paragraph" found "listitem"
** Message: searching for "paragraph" found "paragraph"
And dies.
Dies??? Could it be downloading of DTDs?
( http://bugzilla.gnome.org/show_bug.cgi?id=117469 )
Post by Roberto Rosselli Del Turco
** (conglomerate:4118): WARNING **: unable to convert attribute end
index 4
** (conglomerate:4118): WARNING **: unable to convert attribute end
index 4
I wonder if it's because of some mistakes I could have done in modifying
the TEI lite dispspec to generate the DS one.
I do get those warnings also. However, I don't known what they mean.
This message is just to tell you to not doubt your effort
on adding dispspecs.
Post by Roberto Rosselli Del Turco
Ciao
--
Roberto Rosselli Del Turco roberto.rossellidelturco at unito.it
Geert Stappers
Roberto Rosselli Del Turco
2004-10-23 10:12:52 UTC
Permalink
Post by Geert Stappers
Post by Roberto Rosselli Del Turco
The 13th dispspec (Digital Scriptorium) is the one I added before
launching C.
launching C-compiler?
launching Conglomerate?
( /me telling that I first didn't understood what you mean with 'C' )
That would be Conglomerate, sorry for being too laconic here.
Post by Geert Stappers
Post by Roberto Rosselli Del Turco
Here Conglomerate identifies the DS dispspec as being the closest one to
the document, then prints these lines
** Message: searching for "paragraph" found "admonition"
** Message: searching for "paragraph" found "listitem"
** Message: searching for "paragraph" found "paragraph"
And dies.
Dies??? Could it be downloading of DTDs?
( http://bugzilla.gnome.org/show_bug.cgi?id=117469 )
I don't think so: even if my frequent bugging of you guys might lead to
the conclusion that I'm on a flat connection to the Internet, I'm not,
which means that all my XML have a SYSTEM DTD identifier. Anyway, trying
to expand on "dies", here's a backtrace:

** Message: coverage of Digital Scriptorium = 0,991935
** Message: searching for "paragraph" found "admonition"
** Message: searching for "paragraph" found "listitem"
** Message: searching for "paragraph" found "paragraph"

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

** (conglomerate:4579): WARNING **: unable to convert attribute end
index 4
(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
0x0807f417 in cong_editor_line_fragments_get_area_list ()
(gdb) bt
#0 0x0807f417 in cong_editor_line_fragments_get_area_list ()
#1 0x0807fcac in cong_editor_node_generate_line_areas_recursive ()
#2 0x0807ab92 in cong_editor_area_flow_holder_inlines_get_final_node ()
#3 0x0807f2ea in cong_editor_child_policy_inline_new ()
#4 0x0807ee6c in cong_editor_child_policy_insert_areas_for_node ()
#5 0x080853c9 in cong_editor_widget3_node_should_have_editor_node ()
#6 0x0808525a in cong_editor_widget3_get_preedit_data ()
#7 0x08085279 in cong_editor_widget3_get_preedit_data ()
#8 0x08085279 in cong_editor_widget3_get_preedit_data ()
#9 0x08085279 in cong_editor_widget3_get_preedit_data ()
#10 0x08085279 in cong_editor_widget3_get_preedit_data ()
#11 0x08085279 in cong_editor_widget3_get_preedit_data ()
#12 0x08085279 in cong_editor_widget3_get_preedit_data ()
#13 0x08085304 in cong_editor_widget3_get_preedit_data ()
#14 0x080835a8 in cong_editor_widget3_construct ()
#15 0x08083697 in cong_editor_widget3_new ()
#16 0x0809b527 in cong_primary_window_add_doc ()
#17 0x0809ba7b in cong_primary_window_new ()
#18 0x080896ad in open_document_do ()
#19 0x080897cc in open_document ()
#20 0x08089827 in toolbar_callback_open ()

Please note that this is a valid Digital Scriptorium document (checked
with xmllint).
Post by Geert Stappers
I do get those warnings also. However, I don't known what they mean.
This message is just to tell you to not doubt your effort
on adding dispspecs.
Don't worry, I see the potential of Conglomerate and I'm definitely
interested in seeing it make progress. I don't understand if
Conglomerate doesn't load perfectly valid documents because of the
dispspecs or because of other reasons (wrong info in the
/etc/xml/catalog file, f.i.? I surely doesn't include the DTDs I use).

BREAKING NEWS

OK, since I left the compose message window open I can add that I
finally managed to load a DS document: I modified a TEI Lite one, and it
was successfully loaded. Of course Conglomerate was somewhat undecided
about which dispspec should be loaded:

** Message: coverage of TEI Lite = 0,979310
** Message: coverage of Digital Scriptorium = 1,000000

When I tried to edit the dispspec to confirm it was the DS one,
Conglomerate hung with this message:

** ERROR **: file gxx-impl-object-to-xml-tree.c: line 25
(gxx_hash_table_of_children_with_pcdata_to_xml_tree): assertion failed:
(key)
aborting...


Ciao
--
Roberto Rosselli Del Turco roberto.rossellidelturco at unito.it
Dipartimento di Scienze rosselli at ling.unipi.it
del Linguaggio Then spoke the thunder DA
Universita' di Torino Datta: what have we given? (TSE)

Hige sceal the heardra, heorte the cenre,
mod sceal the mare, the ure maegen litlath. (Maldon 312-3)
Dave Malcolm
2004-10-23 10:12:52 UTC
Permalink
Post by Roberto Rosselli Del Turco
Post by Geert Stappers
Post by Roberto Rosselli Del Turco
The 13th dispspec (Digital Scriptorium) is the one I added before
launching C.
launching C-compiler?
launching Conglomerate?
( /me telling that I first didn't understood what you mean with 'C' )
That would be Conglomerate, sorry for being too laconic here.
Post by Geert Stappers
Post by Roberto Rosselli Del Turco
Here Conglomerate identifies the DS dispspec as being the closest one to
the document, then prints these lines
** Message: searching for "paragraph" found "admonition"
** Message: searching for "paragraph" found "listitem"
** Message: searching for "paragraph" found "paragraph"
And dies.
Dies??? Could it be downloading of DTDs?
( http://bugzilla.gnome.org/show_bug.cgi?id=117469 )
I don't think so: even if my frequent bugging of you guys might lead to
the conclusion that I'm on a flat connection to the Internet, I'm not,
which means that all my XML have a SYSTEM DTD identifier. Anyway, trying
** Message: coverage of Digital Scriptorium = 0,991935
** Message: searching for "paragraph" found "admonition"
** Message: searching for "paragraph" found "listitem"
** Message: searching for "paragraph" found "paragraph"
** (conglomerate:4579): WARNING **: unable to convert attribute end
index 4
** (conglomerate:4579): WARNING **: unable to convert attribute end
index 4
(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
0x0807f417 in cong_editor_line_fragments_get_area_list ()
(gdb) bt
#0 0x0807f417 in cong_editor_line_fragments_get_area_list ()
#1 0x0807fcac in cong_editor_node_generate_line_areas_recursive ()
#2 0x0807ab92 in cong_editor_area_flow_holder_inlines_get_final_node ()
#3 0x0807f2ea in cong_editor_child_policy_inline_new ()
#4 0x0807ee6c in cong_editor_child_policy_insert_areas_for_node ()
#5 0x080853c9 in cong_editor_widget3_node_should_have_editor_node ()
#6 0x0808525a in cong_editor_widget3_get_preedit_data ()
#7 0x08085279 in cong_editor_widget3_get_preedit_data ()
#8 0x08085279 in cong_editor_widget3_get_preedit_data ()
#9 0x08085279 in cong_editor_widget3_get_preedit_data ()
#10 0x08085279 in cong_editor_widget3_get_preedit_data ()
#11 0x08085279 in cong_editor_widget3_get_preedit_data ()
#12 0x08085279 in cong_editor_widget3_get_preedit_data ()
#13 0x08085304 in cong_editor_widget3_get_preedit_data ()
#14 0x080835a8 in cong_editor_widget3_construct ()
#15 0x08083697 in cong_editor_widget3_new ()
#16 0x0809b527 in cong_primary_window_add_doc ()
#17 0x0809ba7b in cong_primary_window_new ()
#18 0x080896ad in open_document_do ()
#19 0x080897cc in open_document ()
#20 0x08089827 in toolbar_callback_open ()
This is the well-known "you've nested a structural tag inside a span
tag" crash - Conglomerate doesn't know how to deal with this at the
moment; there's a branch in CVS called "WidgetPlayground" that should be
able to load the file without crashing but doesn't yet support editing -
I'm working on it but it's a hard problem :-(

You can work around the problem by figuring out which tag is causing
problems for Conglomerate, and then converting that span tag into a
structural one in the dispspec. Obviously this sucks.
Post by Roberto Rosselli Del Turco
Please note that this is a valid Digital Scriptorium document (checked
with xmllint).
Post by Geert Stappers
I do get those warnings also. However, I don't known what they mean.
This message is just to tell you to not doubt your effort
on adding dispspecs.
Don't worry, I see the potential of Conglomerate and I'm definitely
interested in seeing it make progress. I don't understand if
Conglomerate doesn't load perfectly valid documents because of the
dispspecs or because of other reasons (wrong info in the
/etc/xml/catalog file, f.i.? I surely doesn't include the DTDs I use).
As explained above, the problem is in Conglomerate, but only manifests
itself for certain document/dispspec combinations.
Post by Roberto Rosselli Del Turco
BREAKING NEWS
OK, since I left the compose message window open I can add that I
finally managed to load a DS document: I modified a TEI Lite one, and it
was successfully loaded. Of course Conglomerate was somewhat undecided
** Message: coverage of TEI Lite = 0,979310
** Message: coverage of Digital Scriptorium = 1,000000
When I tried to edit the dispspec to confirm it was the DS one,
** ERROR **: file gxx-impl-object-to-xml-tree.c: line 25
(key)
aborting...
That should NOT have happened! Please can you post the dispspec that
kills the loader to this list so I can investigate further.
Post by Roberto Rosselli Del Turco
Ciao
Roberto Rosselli Del Turco
2004-10-23 10:12:52 UTC
Permalink
Post by Dave Malcolm
This is the well-known "you've nested a structural tag inside a span
tag" crash - Conglomerate doesn't know how to deal with this at the
moment; there's a branch in CVS called "WidgetPlayground" that should be
able to load the file without crashing but doesn't yet support editing -
I'm working on it but it's a hard problem :-(
I assume you're talking about the dispspec: if there was such an error
in the documents themselves, they wouldn't validate with xmllint or
other parsers/validators, right?
Post by Dave Malcolm
You can work around the problem by figuring out which tag is causing
problems for Conglomerate, and then converting that span tag into a
structural one in the dispspec. Obviously this sucks.
Just to begin with, how can I figure out the troublesome tag?
Post by Dave Malcolm
Post by Roberto Rosselli Del Turco
** ERROR **: file gxx-impl-object-to-xml-tree.c: line 25
(key)
aborting...
That should NOT have happened! Please can you post the dispspec that
kills the loader to this list so I can investigate further.
Here it is, hope someone else on the list is interested in transcription
of medieval manuscripts :)

Ciao
--
Roberto Rosselli Del Turco roberto.rossellidelturco at unito.it
Dipartimento di Scienze rosselli at ling.unipi.it
del Linguaggio Then spoke the thunder DA
Universita' di Torino Datta: what have we given? (TSE)

Hige sceal the heardra, heorte the cenre,
mod sceal the mare, the ure maegen litlath. (Maldon 312-3)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ds.xds
Type: text/xml
Size: 36920 bytes
Desc: not available
Url : http://lists.copyleft.no/pipermail/conglomerate/attachments/20040216/764a0856/ds.xml
Dave Malcolm
2004-10-23 10:12:52 UTC
Permalink
Post by Roberto Rosselli Del Turco
Post by Dave Malcolm
This is the well-known "you've nested a structural tag inside a span
tag" crash - Conglomerate doesn't know how to deal with this at the
moment; there's a branch in CVS called "WidgetPlayground" that should be
able to load the file without crashing but doesn't yet support editing -
I'm working on it but it's a hard problem :-(
I assume you're talking about the dispspec: if there was such an error
in the documents themselves, they wouldn't validate with xmllint or
other parsers/validators, right?
The error is a bug in Conglomerate; both the dispspecs and documents can
be valid and still cause this problem.
Post by Roberto Rosselli Del Turco
Post by Dave Malcolm
You can work around the problem by figuring out which tag is causing
problems for Conglomerate, and then converting that span tag into a
structural one in the dispspec. Obviously this sucks.
Just to begin with, how can I figure out the troublesome tag?
Somewhat fiddly; run Conglomerate under gdb, when it crashes go up the
callstack and find the node causing the problems. Easier said than done
- so I'll look into providing a better error message that tells you what
and where the problem is.
Post by Roberto Rosselli Del Turco
Post by Dave Malcolm
Post by Roberto Rosselli Del Turco
** ERROR **: file gxx-impl-object-to-xml-tree.c: line 25
(key)
aborting...
That should NOT have happened! Please can you post the dispspec that
kills the loader to this list so I can investigate further.
Here it is, hope someone else on the list is interested in transcription
of medieval manuscripts :)
The xds file you attached works fine for me using CVS Conglomerate so
it's either a recently fixed bug or you sent me the wrong file!
Post by Roberto Rosselli Del Turco
Ciao
Roberto Rosselli Del Turco
2004-10-23 10:12:52 UTC
Permalink
Post by Dave Malcolm
Post by Roberto Rosselli Del Turco
Here it is, hope someone else on the list is interested in transcription
of medieval manuscripts :)
The xds file you attached works fine for me using CVS Conglomerate so
it's either a recently fixed bug or you sent me the wrong file!
Wow, that sounds great! Especially since it's the right file :) But did
you manage to download some documents from the DS site to experiment
with? Furthermore, I always had Conglomerate hang when trying to create
a new DS document (New-> Random Document -> Digital Scriptorium -> Apply
-> SEGFAULT): it now works after I've added the full path to the local
copy of the DTD as a SYSTEM ID in the dispspec. Does it work for you
with the public-id="none" system-id="none" values of the dispspec I sent
to the list?

BTW, why force the user to go through an assistant every time he wants
to create a new document?

Ciao
--
Roberto Rosselli Del Turco roberto.rossellidelturco at unito.it
Dipartimento di Scienze rosselli at ling.unipi.it
del Linguaggio Then spoke the thunder DA
Universita' di Torino Datta: what have we given? (TSE)

Hige sceal the heardra, heorte the cenre,
mod sceal the mare, the ure maegen litlath. (Maldon 312-3)
Dave Malcolm
2004-10-23 10:12:52 UTC
Permalink
Post by Roberto Rosselli Del Turco
Post by Geert Stappers
Post by Roberto Rosselli Del Turco
Hi all,
while playing with different dispspecs and the latest 12.pre
Conglomerate, I noticed that if I add a dispspec in the appropriate
directory, Conge goes and try to load it when loading a suitable
document. Unfortunately, the few documents I tried to load crashed
costantly: is it because Conglomerate needs to be compiled with the
dispspec name in the makefile? It would be nice to be able to modify
current dispspecs, then drop the modified versions in the dispspec
directory and have them work automagically; especially with complex DTDs
like TEI, where, as I hinted in the past, you can have lots of custom
subset-DTDs base on the main one.
AFAIK Conglomerate loads the XDS files only during startup.
** Message: Loading xds files from "/home/roby/.conglomerate/dispspecs"
CongDispspecRegistry contains 14 dispspec(s)
ds[0] = "Experimental "cnxml" format"
ds[1] = "Name of this document type"
ds[2] = "Experimental "readme" format"
ds[3] = "RELAX NG"
ds[4] = "Website Layout"
ds[5] = "Webpage"
ds[6] = "XSL stylesheet"
ds[7] = "DocBook"
ds[8] = "Conglomerate Display Specification"
ds[9] = "Apache Documentation DTD v1.2"
ds[10] = ""Kernel Traffic" Newsletter"
ds[11] = "XHTML 1.0 (strict)"
ds[12] = "TEI Lite"
ds[13] = "Digital Scriptorium"
The 13th dispspec (Digital Scriptorium) is the one I added before
launching C.
Post by Geert Stappers
IIRC there is _in_ conge a display spec file edit function,
that can reload the fresh edited dot xds.
Having to restart Conglomerate in case you add a new dispspec doesn't
look particularly cumbersome, provided that dropping it in the
appropriate directory and restarting the program actually means having
the dispspec working. In fact, this is what happens when I try to load a
** Message: coverage of TEI Lite = 0,838710
** Message: coverage of Digital Scriptorium = 0,991935
Here Conglomerate identifies the DS dispspec as being the closest one to
the document, then prints these lines
** Message: searching for "paragraph" found "admonition"
** Message: searching for "paragraph" found "listitem"
** Message: searching for "paragraph" found "paragraph"
Please post a backtrace from gdb to the list; we can tell you how to do
this if need be.
Post by Roberto Rosselli Del Turco
** (conglomerate:4118): WARNING **: unable to convert attribute end
index 4
** (conglomerate:4118): WARNING **: unable to convert attribute end
index 4
I wonder if it's because of some mistakes I could have done in modifying
the TEI lite dispspec to generate the DS one.
Ciao
Dave Malcolm
2004-10-23 10:12:52 UTC
Permalink
Post by Roberto Rosselli Del Turco
Hi all,
while playing with different dispspecs and the latest 12.pre
Conglomerate, I noticed that if I add a dispspec in the appropriate
directory, Conge goes and try to load it when loading a suitable
document. Unfortunately, the few documents I tried to load crashed
costantly: is it because Conglomerate needs to be compiled with the
Please supply a backtrace of the crash (I suspect it's the usual
"nesting structural tags inside span ones" problem)
Post by Roberto Rosselli Del Turco
dispspec name in the makefile? It would be nice to be able to modify
current dispspecs, then drop the modified versions in the dispspec
directory and have them work automagically; especially with complex DTDs
like TEI, where, as I hinted in the past, you can have lots of custom
subset-DTDs base on the main one.
Can't be done at the moment; there simply isn't any infrastructure to
deal with changes to a dispspec, alas.

Hacking the "installed" version of the xds file ought to work, provide
you restart Conglomerate each time, which would be a pain.
Post by Roberto Rosselli Del Turco
Ciao
Loading...