DOCBOOK: re: Modularity and PE reorganization
From: Norman Walsh [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: DOCBOOK: Modularity and PE reorganization Date: Mon, 09 Sep 2002 10:44:28 -0400 I spent some time this weekend with several hundred little slips of paper[1] making a stab at a more logical set of parameter entities (or at least, of classes) for DocBook. Wouldn't using physical tokens, for each element, imply that they can only belong to one class or module? Certainly, where multiple interpretations of a term exist (e.g. module, class, package, etc.), some duplication is acceptable and should even be encouraged. Using separate namespaces (if possible) for each module would help disambiguate collisions (for purposes of authoring, documenting, and processing, actually). Hopefully, allowing duplication of elements would eliminate nearly all of the tough classification decisions. Furthermore, being able to put them in different namespaces would allow their content models to differ. Anyhow, one thing I noticed about your categorization is that you put a number of document structures in a publishing class (e.g. figure, blockquote), yet you put things I consider to be publishing (i.e. referring to a context outside of the document) in a core class (e.g. edition, pubdate, publisher, issuenum). I think the fundamental blocks found in all types of documents (e.g. para, figure, etc.) should form the core, while larger-scale blocks (e.g. chapter, part, article) would go in a 'document' class (as opposed to a website class, letter class, resume class, etc.). Then, domain-specific terms (with publishing being considered a domain) should go in their own modules (BTW, I'd put revhistory in publishing). Thank you for considering my feedback. Matt Gruenke _ Send and receive Hotmail on your mobile device: http://mobile.msn.com
XInclude vs. external entities (Re: DOCBOOK: The best way to 'include'parts...)
From: Janning Vygen [EMAIL PROTECTED] To: Ljósálfr [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: DOCBOOK: The best way to 'include' parts of a DocBook Date: Tue, 10 Sep 2002 17:52:02 +0200 I use XInclude all the time and by now i see no disadvantage over external entities. The advantages of entities derive from the fact that the mechanism provides a level of indirection - the name of a chunk is decoupled from its address. Indirection carries a fundamental tradeoff of locality vs. centralized management (e.g. you must define an entity, before you can use it, but the !ENTITY ... declaration has the advantage that by centralizing this mapping, the address of a chunk can be changed in a single place). Also, indirection carries with it the potential to override the address (or even the value, in the case of entities), or for it to be externally specified. One of my favorite techniques is for a document chunk (itself an entity) to reference entities it (i.e. its mating external parameter entity) doesn't define (or that it does define, but which the parent overrides). This allows reusable content that is customizable by the parent, and can be used with entities as small as a term (e.g. a product name) to ones as large as figures, tables, paragraphs, whole document chunks, etc. I don't mean to imply that XInclude is bad - it probably serves as a suitable replacement for external entities, most of the time. The primary benefit is that it's conceptually and functionally simpler. However, I wanted to cite some usage models you (and other XInclude advocates) may have been overlooking. The external entity facility is a powerful tool in structuring modular documentation - one which I'd never willingly give up. Matt Gruenke _ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com
Re: XInclude vs. external entities (Re: DOCBOOK: The best way to'include' parts...)
Am Mittwoch, 11. September 2002 05:30 schrieb Matt G.: From: Janning Vygen [EMAIL PROTECTED] To: Ljósálfr [EMAIL PROTECTED], [EMAIL PROTECTED] I use XInclude all the time and by now i see no disadvantage over external entities. The advantages of entities derive from the fact that the mechanism provides a level of indirection - the name of a chunk is decoupled from its address. Indirection carries a fundamental tradeoff of locality vs. centralized management (e.g. you must define an entity, before you can use it, but the !ENTITY ... declaration has the advantage that by centralizing this mapping, the address of a chunk can be changed in a single place). Also, indirection carries with it the potential to override the address (or even the value, in the case of entities), or for it to be externally specified. ok, you are right in this point. If i include a fiel a lots of time with XInclude and ichange its location i have to change the url in every href attribute of XInclude. Question: Can I use XMLCatalog with XInclude. Dont know much about XMLCatalogs but i think you can do a url to filename mapping with it. If xou could use it together with XInclude then you get back the level of indirection Another important advantage of XInclude is the possibility to put doctype declaration in the modular doc to validate it seperatly from the main document AND you can use entites in each file which is not possible within external entities. And take a look at the powerful combination to use XInclude together with XPath to include just parts which match the XPath expression. kind regards, janning One of my favorite techniques is for a document chunk (itself an entity) to reference entities it (i.e. its mating external parameter entity) doesn't define (or that it does define, but which the parent overrides). This allows reusable content that is customizable by the parent, and can be used with entities as small as a term (e.g. a product name) to ones as large as figures, tables, paragraphs, whole document chunks, etc. I don't mean to imply that XInclude is bad - it probably serves as a suitable replacement for external entities, most of the time. The primary benefit is that it's conceptually and functionally simpler. However, I wanted to cite some usage models you (and other XInclude advocates) may have been overlooking. The external entity facility is a powerful tool in structuring modular documentation - one which I'd never willingly give up. Matt Gruenke
DOCBOOK: example of Element tgroup with it's attribute cols .
Hi anyone with an example of Element tgroup with it's attribute cols . I am trying to get the columns to work without Elements /row /entry Don't understand how to invoke NMTOKEN datatype as it's#REQURIED for Element /tgroup Please point or illustrate Cheers all. -- Regards Chuck Amadi ICT Dept Systems Programmer Rhaglenydd Systemau Adran ICT
DOCBOOK: Re: XInclude vs. external entities (Re: The best way to'include' parts...)
/ Janning Vygen [EMAIL PROTECTED] was heard to say: | ok, you are right in this point. If i include a fiel a lots of time | with XInclude and ichange its location i have to change the url in | every href attribute of XInclude. If I was going to use XInclude in my own system, I'd use URNs and allow the URI resolver to get the right filename: xi:include href=urn:publicid:-:Norman+Walsh:Document+My+File:EN/ Indirection is a good thing! | Question: Can I use XMLCatalog with XInclude. Dont know much about | XMLCatalogs but i think you can do a url to filename mapping with it. | If xou could use it together with XInclude then you get back the | level of indirection Exactly. | Another important advantage of XInclude is the possibility to put | doctype declaration in the modular doc to validate it seperatly from | the main document AND you can use entites in each file which is not | possible within external entities. Yes, that's a win. Be seeing you, norm -- Norman Walsh [EMAIL PROTECTED] | 'tis expressly against the law of http://www.oasis-open.org/docbook/ | arms: 'tis as arrant a piece of Chair, DocBook Technical Committee | knavery, mark you now, as can be | offer't; in your conscience, now, | is it not?--Fluellen, Henry V
DOCBOOK: Re: Modularity and PE reorganization
/ Matt G. [EMAIL PROTECTED] was heard to say: |I spent some time this weekend with several hundred little slips of |paper[1] making a stab at a more logical set of parameter entities (or |at least, of classes) for DocBook. | | Wouldn't using physical tokens, for each element, imply that they can | only belong to one class or module? Certainly, where multiple One of the constraints of the Maler+Andaloussi[1] class/mixture methodology is that an element can appear in at most one class. | interpretations of a term exist (e.g. module, class, package, | etc.), some duplication is acceptable and should even be encouraged. | Using separate namespaces (if possible) for each module would help | disambiguate collisions (for purposes of authoring, documenting, and | processing, actually). If they are in different namespaces, they are not the same. Assuming that a: and b: are mapped to different namespace names, a:foo and b:foo are as different as foo and bar. | Hopefully, allowing duplication of elements would eliminate nearly all | of the tough classification decisions. Furthermore, being able to put | them in different namespaces would allow their content models to | differ. The classification decisions turned out to be not too hard. Figuring out what the right content models are (the mixtures) is proving a little more interesting. But I haven't been thinking about it as long. Moving to multiple namespaces isn't in the cards at the moment. | Anyhow, one thing I noticed about your categorization is that you put | a number of document structures in a publishing class (e.g. figure, | blockquote), yet you put things I consider to be publishing (i.e. | referring to a context outside of the document) in a core class | (e.g. edition, pubdate, publisher, issuenum). I think the fundamental The former are elements that appear in a document as content. The latter are metadata elements. They can't appear in the same sorts of places in a document, so it doesn't make sense to put them in the same class. | blocks found in all types of documents (e.g. para, figure, etc.) | should form the core, One of the goals I'm exploring is a really tiny core. | while larger-scale blocks (e.g. chapter, part, | article) would go in a 'document' class (as opposed to a website They're in a 'book' class. | class, letter class, resume class, etc.). Then, domain-specific terms Letters, resumes, and websites aren't exactly in the computer hardware and software domain. Be seeing you, norm [1] biblioentry id=bib.maler96abbrevMalerAndal96/abbrev titleDeveloping SGML DTDs/title subtitleFrom Text to Model to Markup/subtitle authorgroup author firstnameEve/firstname surnameMaler/surname /author author firstnameJeanne/firstname surnameEl Andaloussi/surname /author /authorgroup isbn0-13-309881-8/isbn publisher publishernamePrentice-Hall PTR/publishername address cityUpper Saddle River/city stateNew Jersey/state /address /publisher pubdate1996/pubdate /biblioentry -- Norman Walsh [EMAIL PROTECTED] | 'tis expressly against the law of http://www.oasis-open.org/docbook/ | arms: 'tis as arrant a piece of Chair, DocBook Technical Committee | knavery, mark you now, as can be | offer't; in your conscience, now, | is it not?--Fluellen, Henry V
RE: DOCBOOK: Re: XInclude vs. external entities (Re: The best way to'include' parts...)
I've been trying to download the URI resolver from http://wwws.sun.com/software/xml/developers/resolver/ for two weeks now; keep getting some transaction error. Is there any alternative location where I could get it?... Thanks a lot -Original Message- From: ed nixon [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 11, 2002 17:23 To: Norman Walsh Cc: [EMAIL PROTECTED] Subject: Re: DOCBOOK: Re: XInclude vs. external entities (Re: The best way to 'include' parts...) Norman Walsh wrote: snip/ If I was going to use XInclude in my own system, I'd use URNs and allow the URI resolver to get the right filename: xi:include href=urn:publicid:-:Norman+Walsh:Document+My+File:EN/ Sorry, Norm. Could you please give a real example. I am confused by the proliferation of dashes, colons and plus signs. I sort of see a PUBLIC identifier there but I'm not sure and I don't make a connection to where this resolution takes place, how this href string is broken down and then put back together again. Little steps, please. A pointer to some documentation on this would be a help, as well. Thanks, this is really looking interesting as a win-win situation. ...edN
Re: DOCBOOK: Re: XInclude vs. external entities (Re: The best wayto'include' parts...)
Zhuravleva, Tatyana wrote: I've been trying to download the URI resolver from http://wwws.sun.com/software/xml/developers/resolver/ for two weeks now; keep getting some transaction error. Is there any alternative location where I could get it?... You can get it from xml.apache.org as well. -- - Jirka Kosek e-mail: [EMAIL PROTECTED] http://www.kosek.cz
Re: DOCBOOK: Re: XInclude vs. external entities (Re: The best way to'include' parts...)
Ok, now some bells are ringing, faintly. Obviously this is Java code. My understanding is that XInclude is only implemented in xsltproc, etc.; is this an error on my part? Does xsltproc have URI resolver capabilities? Thanks again. ...edN Zhuravleva, Tatyana wrote: I've been trying to download the URI resolver from http://wwws.sun.com/software/xml/developers/resolver/ for two weeks now; keep getting some transaction error. Is there any alternative location where I could get it?... Thanks a lot snip/ Norman Walsh wrote: snip/ If I was going to use XInclude in my own system, I'd use URNs and allow the URI resolver to get the right filename: xi:include href=urn:publicid:-:Norman+Walsh:Document+My+File:EN/ Sorry, Norm. Could you please give a real example. I am confused by the proliferation of dashes, colons and plus signs. I sort of see a PUBLIC identifier there but I'm not sure and I don't make a connection to where this resolution takes place, how this href string is broken down and then put back together again. Little steps, please. A pointer to some documentation on this would be a help, as well. Thanks, this is really looking interesting as a win-win situation. ...edN
DOCBOOK: Re: XInclude vs. external entities (Re: The best way to'include' parts...)
/ Zhuravleva, Tatyana [EMAIL PROTECTED] was heard to say: | I've been trying to download the URI resolver from | http://wwws.sun.com/software/xml/developers/resolver/ | for two weeks now; keep getting some transaction error. Bleh. | Is there any alternative location where I could get it?... Yes, it's part of the XML Commons package at xml.apache.org. Be seeing you, norm -- Norman Walsh [EMAIL PROTECTED] | 'tis expressly against the law of http://www.oasis-open.org/docbook/ | arms: 'tis as arrant a piece of Chair, DocBook Technical Committee | knavery, mark you now, as can be | offer't; in your conscience, now, | is it not?--Fluellen, Henry V
DOCBOOK: Re: XInclude vs. external entities (Re: The best way to'include' parts...)
/ ed nixon [EMAIL PROTECTED] was heard to say: | Ok, now some bells are ringing, faintly. | | Obviously this is Java code. My understanding is that XInclude is only | implemented in xsltproc, etc.; is this an error on my part? Nope. | Does xsltproc have URI resolver capabilities? Yep. DV is *da man*. :-) Be seeing you, norm -- Norman Walsh [EMAIL PROTECTED] | 'tis expressly against the law of http://www.oasis-open.org/docbook/ | arms: 'tis as arrant a piece of Chair, DocBook Technical Committee | knavery, mark you now, as can be | offer't; in your conscience, now, | is it not?--Fluellen, Henry V
DOCBOOK: Re: example of Element tgroup with it's attribute cols .
/ Chuck Amadi [EMAIL PROTECTED] was heard to say: | How do i get this bugger to work (cols attribute ) I mean I have a | table with three columns and three rows using the The table you provided is invalid in about six different ways. Always use a validating parser to check your work before feeding it to the stylesheets. GIGO applies. Try this: ?xml version=1.0 encoding=utf-8? !DOCTYPE article PUBLIC -//OASIS//DTD DocBook XML V4.2//EN http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd; article id=article titleTable Test/title itemizedlist listitem parandw: do you really want this table in a list item?/para table titlendw: You have to put a title in here/title !-- attribute center doesn't work -- !-- ndw: in what implementation? -- tgroup align=center cols=3 tbody row entryfirst column/entry entrysecond column/entry entrythird column/entry /row row entry !-- This link doesn't work within this table only the watsup text -- !-- ndw: i bet it works now, with more reasonable looking table entry markup -- ulink url=http://watsupwiththis.htm;watsup /ulink /entry /row /tbody /tgroup /table /listitem /itemizedlist /article Be seeing you, norm -- Norman Walsh [EMAIL PROTECTED] | 'tis expressly against the law of http://www.oasis-open.org/docbook/ | arms: 'tis as arrant a piece of Chair, DocBook Technical Committee | knavery, mark you now, as can be | offer't; in your conscience, now, | is it not?--Fluellen, Henry V
DOCBOOK: Referencing examples and figures
Hi there. How do I best go about referencing figures and examples, so that I only get their number in the rendered output, when using the DocBook XSL stylesheets? Example: para Example reference/ shows ... /para example ... /example Output: Example 4.2 shows ... Thanks in advance, Sebastian -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/
DOCBOOK: Re: DOCBOOK-APPS: Interactive reading
Joachim Ziegler wrote: I wonder whether there is a similar mechanism for DocBook. I'm working on a system like this based on DocBook and PHP. I want to offer the same interactive reading experience to the readers of my upcoming book. Once finished, I intend on releasing it as Open Source. Can't say anything on when it's finished, writing the book still comes before publishing it :-) -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/
DOCBOOK: Re: Referencing examples and figures
/ Sebastian Bergmann [EMAIL PROTECTED] was heard to say: | Hi there. | | How do I best go about referencing figures and examples, so that | I only get their number in the rendered output, when using the DocBook | XSL stylesheets? | | Example: | | para | Example reference/ shows ... You want xref here. | Output: | | Example 4.2 shows ... You'll have to tweak the l10n a bit to get rid of the default leading Example. Follow-up to DocBook-apps, please, if you need more help with that. Be seeing you, norm -- Norman Walsh [EMAIL PROTECTED] | 'tis expressly against the law of http://www.oasis-open.org/docbook/ | arms: 'tis as arrant a piece of Chair, DocBook Technical Committee | knavery, mark you now, as can be | offer't; in your conscience, now, | is it not?--Fluellen, Henry V
Re: DOCBOOK: Referencing examples and figures
At 18:22 11/09/2002, Sebastian Bergmann wrote: Hi there. How do I best go about referencing figures and examples, so that I only get their number in the rendered output, when using the DocBook XSL stylesheets? Example: para Example reference/ shows ... /para example ... /example Output: Example 4.2 shows ... para xref=ex1002/ shows . then example id=ex1002 titleBackground and border colours/title programlisting format=linespecific hth DaveP
Re: DOCBOOK: Re: XInclude vs. external entities (Re: The best way to'include' parts...)
Norman Walsh [EMAIL PROTECTED] writes: / Zhuravleva, Tatyana [EMAIL PROTECTED] was heard to say: | I've been trying to download the URI resolver from | http://wwws.sun.com/software/xml/developers/resolver/ | for two weeks now; keep getting some transaction error. Bleh. | Is there any alternative location where I could get it?... Yes, it's part of the XML Commons package at xml.apache.org. Here's a direct link to the download directory: http://xml.apache.org/dist/commons/ Make sure to grab the latest release - currently, xml-commons-1.0.b2 - and note that all you really need from the distribution is the resolver.jar file (in the /java/build/ directory). For the purposes of doing entity and URI resolving, you can safely ignore the rest of the stuff in the xml-commons distro. More details about XML Catalogs and the resolver classes is available at: http://docbook.org/wiki/moin.cgi/DocBookAndXmlCatalogs
