RE: DOCBOOK: Re: Concrete proposal for #480954: Extend textobject toinsert external files

2001-11-14 Thread Christopher R. Maden
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 At 08:38 13-11-2001, Peter Ring wrote: http://www.oreilly.com/people/staff/crism/transclu.html (SGML/XML '97) Just a note: as I left O'Reilly over two years ago, I have no idea how long any content on that web will be available. Please reference

Re: DOCBOOK: Names and addresses

2001-11-14 Thread Christopher R. Maden
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 At 18:12 13-11-2001, Norman Walsh wrote: I think we can break personname out of this: Please - the lack of a name container has long troubled me. ~Chris - -- Christopher R. Maden, Principal Consultant, HMM Consulting Int'l, Inc. DTDs/schemas -

Re: DOCBOOK: Hyphenation of a German text

2001-11-14 Thread Jirka Kosek
Stefan Wintermeyer wrote: simple Problem: I have a German written document. I uses book lang=de for declaring it (is that the mistake?). How can I create a PDF with a correct hyphenation? Evertime I create PDFs it has no hyphentation at all. You must turn on hyphenation in stylesheet. There

DOCBOOK: Re: Names and addresses

2001-11-14 Thread Norman Walsh
In response to some offline comments, I suggest: / Norman Walsh [EMAIL PROTECTED] was heard to say: [...] | Our current tags are | | author ::= | ((honorific|firstname|surname|lineage|othername|affiliation| | authorblurb|contrib)+) | | affiliation ::= |

Re: DOCBOOK: Linking in DocBook V5.0

2001-11-14 Thread Adam Turoff
On Wed, Nov 14, 2001 at 11:07:10AM -0500, Norman Walsh wrote: So my proposal is that we allow most (all?) inline elements to optionally function as simple links. We may also want to allow selected other elements (like funcprototype) to function as simple links as well. Which inline elements

Re: DOCBOOK: Linking in DocBook V5.0

2001-11-14 Thread Jirka Kosek
Adam Turoff wrote: There's a reasonably good case for making block elements such as section and chapter take xlinks as well; it makes it easier to compose larger works from smaller works without resorting to defining entities in the local subset, especially when using xlink:show=embed.

Re: DOCBOOK: Linking in DocBook V5.0

2001-11-14 Thread Daniel Veillard
On Wed, Nov 14, 2001 at 05:47:44PM +0100, Jirka Kosek wrote: Norman Walsh wrote: Given a PE like this: !ENTITY % xlink-optional-simple-link xlink:type (simple)#IMPLIED I think that there should be #FIXED simple, so one is not forced to add xlink:type=simple to

Re: DOCBOOK: Linking in DocBook V5.0

2001-11-14 Thread Jirka Kosek
Daniel Veillard wrote: On Wed, Nov 14, 2001 at 05:47:44PM +0100, Jirka Kosek wrote: Norman Walsh wrote: Given a PE like this: !ENTITY % xlink-optional-simple-link xlink:type (simple)#IMPLIED I think that there should be #FIXED simple, so one is not forced

Re: DOCBOOK: Linking in DocBook V5.0

2001-11-14 Thread Yann Dirson
On Wed, Nov 14, 2001 at 05:47:44PM +0100, Jirka Kosek wrote: 1. Switch. Remove linkend and break everything all at once. This is not good approach, IMHO. Seconded. 2. Allow both in V5 and remove linkend in V6. Stipulating that when both are present linkend wins (or xlink:href wins,

DOCBOOK: Re: Linking in DocBook V5.0

2001-11-14 Thread Norman Walsh
/ Adam Turoff [EMAIL PROTECTED] was heard to say: | On Wed, Nov 14, 2001 at 11:07:10AM -0500, Norman Walsh wrote: | Which inline elements do you mean here (i.e., which PE definitions)? | Or, do you mean anything that can be found inside of para? I mean essentially all the inlines (filename,

DOCBOOK: Re: Linking in DocBook V5.0

2001-11-14 Thread Norman Walsh
/ Jirka Kosek [EMAIL PROTECTED] was heard to say: | I think that show=embed is used for including separate objects in | on-line presentation. If you want to split your document into several | files you should use entities or XInclude (with parse=xml) langauge. Right. XLink embed embeds the

DOCBOOK: Re: Linking in DocBook V5.0

2001-11-14 Thread Norman Walsh
/ Jirka Kosek [EMAIL PROTECTED] was heard to say: | Norman Walsh wrote: | | Given a PE like this: | | !ENTITY % xlink-optional-simple-link | xlink:type (simple)#IMPLIED | | I think that there should be #FIXED simple, so one is not forced to | add xlink:type=simple to every

DOCBOOK: Re: Linking in DocBook V5.0

2001-11-14 Thread Norman Walsh
/ Jirka Kosek [EMAIL PROTECTED] was heard to say: | OK. But in that case, there should be at least: | | xlink:type (simple|extended)#IMPLIED I disagree. I don't want phrase to be an extended link. Ever. But it can be a simple link, sometimes.

DOCBOOK: Re: Linking in DocBook V5.0

2001-11-14 Thread Norman Walsh
/ Daniel Veillard [EMAIL PROTECTED] was heard to say: | I suggest to do this for elements for which DocBook already | has a linking semantic. To anchor that semantic in the syntax. Makes sense. | My point was that for the instance to link to its linkbase, it must | have an element holding

Re: DOCBOOK: Names and addresses

2001-11-14 Thread Bob Stayton
From: Dave Pawson [EMAIL PROTECTED] Then authors (editors, etc) might have this content model: author ::= ((personname, personblurb, affiliation+, email+, address+)) Sounds about right, though what of 'person's without affiliations? i.e. the great unemployed / self employed?

Re: DOCBOOK: Linking in DocBook V5.0

2001-11-14 Thread Dave Pawson
At 18:13 14/11/2001 +0100, Jirka Kosek wrote: OK. So lets have extended links in DocBook. With ~400 elements, DocBook always provided features that most users didn't use, but they were there for few people who needed them. Lot of truth in that Norm! The XML ahead is a docbook instance?

DOCBOOK: Re: Names and addresses

2001-11-14 Thread Norman Walsh
/ Bob Stayton [EMAIL PROTECTED] was heard to say: | From: Dave Pawson [EMAIL PROTECTED] | | Then authors (editors, etc) might have this content model: | | author ::= | ((personname, personblurb, affiliation+, email+, address+)) | | | Sounds about right, though what of 'person's

Re: DOCBOOK: Re: Linking in DocBook V5.0

2001-11-14 Thread Daniel Veillard
On Wed, Nov 14, 2001 at 02:06:07PM -0500, Norman Walsh wrote: / Daniel Veillard [EMAIL PROTECTED] was heard to say: | Should xlink:type=extended be forbidden still ? I'm tempted to not | block them on a general basis. If there is elements with a predefined linking | semantic, then fixing

Re: DOCBOOK: Linking in DocBook V5.0

2001-11-14 Thread Elliotte Rusty Harold
At 11:56 AM -0500 11/14/01, Daniel Veillard wrote: Is there anybody who need to use extended links? If there is no stress Yes, me. I want to be able to use external link bases containing generic indexes for a collections of documents at least. Yes, but the point of external linkbases is

Re: DOCBOOK: Re: Linking in DocBook V5.0

2001-11-14 Thread Elliotte Rusty Harold
I think most, perhaps all, DocBook elements should be allowed to be simple links. I can easily imagine making a para or a listitem or a table cell a link. Certainly the various kinds of images and examples might be links. I don't think we should restrict this to just inline elements. --

Re: DOCBOOK-APPS: Re: toc frame in slides

2001-11-14 Thread Yann Dirson
On Tue, Nov 13, 2001 at 07:55:32PM -0500, Norman Walsh wrote: So, does anyone know what the official separator is for a locale variation? Hard to find... Looking at http://www-4.ibm.com/software/webservers/appserv/doc/v40/aes/infocenter/was/060649.html it appears to be @. -- Yann Dirson

Re: DOCBOOK-APPS: Mandrake DSSSL and jadetex customizations

2001-11-14 Thread Allin Cottrell
Some people asked about an English version of the French report by Pascal Lo Re, which explains the Mandrake customizations. I have done a rough-and-ready translation. It's at http://ricardo.ecn.wfu.edu/~cottrell/mandrake-sgml/ Could a Mandrake person let me know if they're OK with this? If

DOCBOOK-APPS: Re: toc frame in slides

2001-11-14 Thread Norman Walsh
Great, so we have '.', '@', and '_' all fighting it out. | Is there such a specification for variations? | Or are you defining it here? ;-) I guess I'm defining it, but I'd like to follow *some* convention. :-) The idea is that I'd allow variations in localizations: i18n

RE: DOCBOOK-APPS: Re: toc frame in slides

2001-11-14 Thread Bob Stayton
The Open Group (formerly X/Open) uses underscore between language and country code. I couldn't find any ISO standard that defines the whole locale string, just separate standards for language codes and country codes. bobs From

DOCBOOK-APPS: Re: toc frame in slides

2001-11-14 Thread Norman Walsh
/ David Cramer [EMAIL PROTECTED] was heard to say: | I've seen it with another underscore, e.g. fr_FR_EURO | See: http://oss.software.ibm.com/icu/userguide/locale.html Yes, Java seems to suggest the underscore. But doesn't that introduce ambiguity? Suppose I want English, I don't care what

Re: DOCBOOK-APPS: Re: toc frame in slides

2001-11-14 Thread Eric Richardson
Norman Walsh wrote: / David Cramer [EMAIL PROTECTED] was heard to say: | I've seen it with another underscore, e.g. fr_FR_EURO | See: http://oss.software.ibm.com/icu/userguide/locale.html Yes, Java seems to suggest the underscore. But doesn't that introduce ambiguity? Suppose I want

FW: DOCBOOK-APPS: Simple lists

2001-11-14 Thread Phillip Shelton
Dopey me. That is with DSSSL 1.73 against Docbookx 4.1.2 -Original Message- From: Phillip Shelton [mailto:[EMAIL PROTECTED]] Sent: Thursday, 15 November 2001 11:04 To: DocBook-Apps ML (E-mail) Subject: DOCBOOK-APPS: Simple lists Processing. Is there any way to over-ride the

RE: DOCBOOK-APPS: Simple lists

2001-11-14 Thread Phillip Shelton
-Original Message- [snip] and is it possible to get the inline to add 'and' between the secondlast and last elements? Don't worry about this as I want it to add 'and' in one list and 'or' in another about four lines further down. -Original Message- Dopey me. That is