OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

Mail Index message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: docbook-digest Digest #193

Re: DOCBOOK: XHTML tables
Re: DOCBOOK: DocBook vs OpenOffice.org
Re: DOCBOOK: XHTML tables
DOCBOOK: Re: syntax=""
DOCBOOK: Re: marking up keycaps according to their semantics
DOCBOOK: Re: XHTML tables
DOCBOOK: Re: XHTML tables
DOCBOOK: Re: Which element should be used as a status ?
DOCBOOK: Re: Documenting extensions
Re: DOCBOOK: marking up keycaps according to their semantics
Re: DOCBOOK: The right tool for my task
Re: DOCBOOK: XHTML tables
Re: DOCBOOK: XHTML tables
Re: DOCBOOK: XHTML tables
Re: DOCBOOK: XHTML tables
Re: DOCBOOK: Re: XHTML tables
Re: DOCBOOK: Re: marking up keycaps according to their semantics
Re: DOCBOOK: Re: XHTML tables
Re: DOCBOOK: Re: XHTML tables
DOCBOOK: Re: marking up keycaps according to their semantics
Re: DOCBOOK: Re: marking up keycaps according to their semantics

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>


Jirka Kosek wrote:


> P.S. For everyone else: I know that this discussion is getting quite
> tedious,


Since you are aware of that fact ...

> but at least TC will have some input from users. 


Discussing this topic is fine; turning in circles is not.


Tobi


-- 
http://www.pinkjuice.com/




On Wed, Mar 05, 2003 at 02:58:57AM +0100, Florian Brunner wrote:
> Ok, I know that OpenOffice.org is a whole application suite, but I meant 
> actually only the word processing part. It's also "simply a bunch of text 
> surrounded by XML tags" which in addition happens to know how to format 
> itself. But since its file-format is XML you can also transform it easily 
> (more or less) to other output formats. So again my questions:
> What would be the advantages of using DocBook instead of OpenOffice.org? What 
> the disadvantages?
> For what task would you suggest the one and for what the other?

  Hum, from my recolection of reading the OO XML specification, it
seems to be at a lower semantic level than DocBook markup, i.e. it's
more close to serializing OO internal datastructure than a generic
markup intended to encapsulate a lot of information about the text
been marked up. That's relatively logical, OO interface doesn't 
ask you for logical information about the text being input. So OO
composition is "easier" but encapsulate less semantic. So I would
target OO format when you intend to use OO to maintain the document
and rather DocBook if you intend to use the document as a source for
various documentation and metadata processes.

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard@redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/



Tobias Reif wrote:

> Discussing this topic is fine; turning in circles is not.

Well you have proposed using HTML tables in their own namespaces. Could
you please cut circle and show me and the other folks how this will
work? I'm really concerned that this is not very usable solution,
because:

You will either need to prefix all HTML table elements and you wouldn't
be then
able to cut'n'paste from HTML. 

<html:table xmlns:html="http://www.w3.org/1999/xhtml">
  <html:tr>
    <html:td>Cell with <emphasis>emphasized words</emphasis></html:td>
  </html:tr>
</html:table>

Or you will use default namespace for 
table element, so there won't be need for prefixing, but then you will
be forced to change default namespace for table cell content. And this
will be hassle as table cell can contain mixed content.

<table xmlns="http://www.w3.org/1999/xhtml">
  <tr>
    <td>Cell with <emphasis
xmlns="urn:x-example:schemas:docbook:5.0">emphasized
words</emphasis></td>
  </tr>
</table>

Which style from these two did you preffer?  Or do you have any other
solution which won't be as complex? 

				Jirka

-- 
-----------------------------------------------------------------
  Jirka Kosek  	                     
  e-mail: jirka@kosek.cz
  http://www.kosek.cz



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

/ Tobias Reif <tobiasreif@pinkjuice.com> was heard to say:
| Norman Walsh wrote:
|
|> | Should I file an RFE?
|> Sure.
|
| Done:
| http://snurl.com/v2i
| (RFE 692319)
| (second try; first one disappeared)

Uhm, I think I moved it because I thought you'd put it in a different
place than I had in mind. No worries.

                                        Be seeing you,
                                          norm

- -- 
Norman Walsh <ndw@nwalsh.com>      | The First Amendment is often
http://www.oasis-open.org/docbook/ | inconvenient. But that is besides
Chair, DocBook Technical Committee | the point. Inconvenience does not
                                   | absolve the government of its
                                   | obligation to tolerate
                                   | speech.--Justice Anthony Kennedy,
                                   | in 91-155
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.7 <http://mailcrypt.sourceforge.net/>

iD8DBQE+ZStqOyltUcwYWjsRAthhAJsEI1syeF5ABzs1zwlGkalxmGy6mQCgj+vR
NjOuRfvntilxnVdFIzxc57s=
=2jDB
-----END PGP SIGNATURE-----



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

/ Tobias Reif <tobiasreif@pinkjuice.com> was heard to say:
| "Pragmatic Programmer" [1] Dave Thomas writes on his blog [2]:
|
| "[...]
| Here's how the FAQ recommends you mark up the Emacs key sequence C-h
| C-f
| (control H, followed by control F, which normally displays help on a
| function).
|
| <keycombo action="seq">
|    <keycombo action="simul">
|      <keycap>C</keycap>
|      <keycap>h</keycap>
|    </keycombo>
|    <keycombo action="simul">
|      <keycap>C</keycap>
|      <keycap>f</keycap>
|    </keycombo>
| </keycombo>

Uhm, I agree that's not right. This would make more sense:

<keycombo action="seq">
   <keycombo action="simul">
     <keycap>Ctrl</keycap>
     <keycap>h</keycap>
   </keycombo>
   <keycombo action="simul">
     <keycap>Ctrl</keycap>
     <keycap>f</keycap>
   </keycombo>
</keycombo>

But the truth of the matter is, I'm not sure this information is worth
marking up in this level of detail. I'd probably use something much simpler.

Dave is confusing the ability to do something with the requirement
that one do it that way. But nevermind.

| \KeySeq{\Control{h} \Control{f}}
|
| This (to my mind) a lot easier to read and type. But more importantly,

Yes, but it's not easy to turn that into a structure that can be
manipulated with general purpose tools. Terseness of markup is
explicitly NOT a goal of XML.

| it gives me the flexibility I need. Perhaps in online documentation I
| want to use the 'C-h' convention. No problem, I just write the macro
| appropriately and every control sequence is documented accordingly. If
| a publication says that their standard for control keys is "^h ^f",
| then a single change to the macro updates the whole document. And if I
| want to use fancy pictures of keys, my macros can do that too.

Yeah, if all you want is macro substitution, all you need is, uhm,
macro substitution.

What if you want to do something more interesting, like test your
source to make sure the quick reference includes all the keyboard
commands actually used. Or make sure that the accessibility guidelines
are met by pairing semantic gestures with the mouse with keyboard
commands. Or any of a thousand other things that would be impossible
with macro substitutions.

| I agree that there should be a way to markup the control key as control key.
| If we choose what's printed on the key, then that would be Strg for
| German keyboeards, Ctrl for english ones, etc.
| role="control-ley" doesn't cut it either; it would work with one set
| of transformation tools, but not with a different set.

Well, I think I'd be tempted to recognize <keycap>Ctrl</keycap> and
translate it directly into another language without adding more markup
to make it more "semantic".

                                        Be seeing you,
                                          norm

- -- 
Norman Walsh <ndw@nwalsh.com>      | Everything we love, no doubt, will
http://www.oasis-open.org/docbook/ | pass away, perhaps tomorrow,
Chair, DocBook Technical Committee | perhaps a thousand years hence.
                                   | Neither it nor our love for it is
                                   | any the less valuable for that
                                   | reason.--John Passmore
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.7 <http://mailcrypt.sourceforge.net/>

iD8DBQE+ZS2HOyltUcwYWjsRAtmKAKCip1YrNwzR3kIoKvRkKJEvMbV8+wCfW4ZJ
xNqNIlyZkQLXauVnrjkvuJk=
=YvR6
-----END PGP SIGNATURE-----



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

/ Jirka Kosek <jirka@kosek.cz> was heard to say:
| But HTML table model in DocBook breaks backward compatibility and it
| isn't easy to integrate both CALS and HTML tables at the same time (you
| will get very relaxed DTD for tables which will allow you to create
| mangled CALS+HTML tables)

Paul did some work to demonstrate that the opportunities for mangling
aren't all that great. You can really only mix things at the
thead/tfoot/tbody level.

| And creating two DocBooks -- one with HTML
| tables and second with CALS ones is also not good idea.

Nope. I don't want to do that.

                                        Be seeing you,
                                          norm

- -- 
Norman Walsh <ndw@nwalsh.com>      | Is your cucumber bitter? Throw it
http://www.oasis-open.org/docbook/ | away. Are there briars in your
Chair, DocBook Technical Committee | path? Turn aside. That is enough.
                                   | Do not go on to say, 'Why were
                                   | things of this sort ever brought
                                   | into the world?'--Marcus Aurelius
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.7 <http://mailcrypt.sourceforge.net/>

iD8DBQE+ZS3dOyltUcwYWjsRAmO3AJ9RR2PSFVcQ32XYDwkyyzuSoncn1gCfVlad
C/L0DkdIHmWfRQ+8Ca1BpeY=
=X8/h
-----END PGP SIGNATURE-----



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

/ Jirka Kosek <jirka@kosek.cz> was heard to say:
| P.S. For everyone else: I know that this discussion is getting quite
| tedious, but at least TC will have some input from users. Which is not
| case for all issues. :-(

Keep it up. I'd be delighted if another 100 folks would chime in.


                                        Be seeing you,
                                          norm

- -- 
Norman Walsh <ndw@nwalsh.com>      | For the mental patient's family
http://www.oasis-open.org/docbook/ | and society, mental illness is a
Chair, DocBook Technical Committee | 'problem'; for the patient himself
                                   | it is a 'solution'.--Thomas Szasz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.7 <http://mailcrypt.sourceforge.net/>

iD8DBQE+ZS51OyltUcwYWjsRAq/bAJ9VYPT6Z5kjHBvUZuyjQnKY3qNa7gCgnoao
03elrAU14+c2xIzE29J5bH0=
=BhD9
-----END PGP SIGNATURE-----



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

/ Frédéric Glorieux <frederic.glorieux@ajlsm.com> was heard to say:
| I'm a newbie to Docbook (but not in XML and relative standards).
| I'm beginning a documentation in this schema, and I've got some (bad?)
| habits from other namespaces (standard or personal).
| For example, I'm usually using a <status/> element at the beginning of
| an article or a book (like in a W3C spec). What should I use in docbook
| for this meaning?

It depends on what you want to say. I often use a legalnotice as a
kind of status in *info elements (with an appropriate role). There's
also an attribute to show the publication status.

| <concept/> to tag the master idea of a block (useful for future
| indexation)

You can use indexterm to mark index terms, but DocBook doesn't have
the notion of an inline concept. The catch-all for things like this is
phrase with a role attribute.

| <definition/> or <dfn/> to tag the definition of the concept

Since DocBook is about software documentation, you can usually use the
tag that identifies what it is. The notion of an inline definition,
like a concept, isn't directly supported.

| <samp/> or <example/> to tag an example relative to the definition

Programlisting or screen or literallayout are common choices.

                                        Be seeing you,
                                          norm

- -- 
Norman Walsh <ndw@nwalsh.com>      | So, are you working on finding
http://www.oasis-open.org/docbook/ | that bug now, or are you leaving
Chair, DocBook Technical Committee | it until later? Yes.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.7 <http://mailcrypt.sourceforge.net/>

iD8DBQE+ZSsNOyltUcwYWjsRAkAXAJ9C4vO/ST94vDGKSi8LVvJGUq2BhQCgitTO
YkdNNm3PcdBU6Y9cK0h2yow=
=zYsU
-----END PGP SIGNATURE-----



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

/ Henrik Motakef <henrik.motakef@web.de> was heard to say:
| I'm playing with a Docbook extension, and of course would like to
| document it using Docbook. I wonder, are the tools used for TDG (that
| produce all those *.gen files) available somewhere?

They're surely in CVS in the defguide/en/build directory. But they're
not well documented, so you may have to ask for help.

                                        Be seeing you,
                                          norm

- -- 
Norman Walsh <ndw@nwalsh.com>      | Extinction, n. The raw material
http://www.oasis-open.org/docbook/ | out of which theology created the
Chair, DocBook Technical Committee | future state.--Ambrose Bierce
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.7 <http://mailcrypt.sourceforge.net/>

iD8DBQE+ZS/POyltUcwYWjsRApjVAJ4+QCP3+YBF5+3HpM9WF0+iwNoKrwCdEkQo
6o5HdKwan7mp72PnPuZEmzI=
=2Taw
-----END PGP SIGNATURE-----



I suggest you take this nice clear explanation and paste it
into a DocBook RFE on the DocBook SourceForge site.  There
is a section in the Tracker for "DocBook RFEs" just for
things like this.  That's will get it on the Technical
Committee's agenda.

Bob Stayton                                 400 Encinal Street
Publications Architect                      Santa Cruz, CA  95060
Technical Publications                      voice: (831) 427-7796
The SCO Group                               fax:   (831) 429-1887
                                            email: bobs@sco.com

On Tue, Mar 04, 2003 at 04:18:11PM +0100, Tobias Reif wrote:
> Bob
> 
> > Let me see if I understand you.  You are suggesting that
> > the DTD be changed
> 
> 
> Yes, probably best extended.
> 
> > so that keycap can have a way of
> > identifying certain keys that have functions that go
> > beyond entering a character.
> 
> 
> Yep; many keys don't really enter characters (where character is 
> something which very closely is tied to a certain set of glyphs).
> 
> > You want to capture the
> > semantic concept of a Ctrl key, so that it can be expressed
> > by the stylesheets in many ways rather than as a literal
> > key name, right?
> 
> 
> yep :)
> 
> > So for Emacs doc, a stylesheet would
> > render it as "C", while another stylesheet would
> > say "Ctrl". In other languages it could be
> > translated by the gentext files.
> 
> 
> This would be one of the advantages of a more semantic notation, yes.
> 
> Generate "ctrl" in the English version, "strg" in the German one, etc.
> 
> 
> > This would seem to apply to just a few keys, like
> > Alt, Esc, Shift, and Ctrl at least.  Maybe Enter as well?
> > Or should it be for all the named keys, including Insert,
> > Home, etc.?
> 
> 
> This would need to be discussed. But I'm sure we could specify a list 
> which makes sense as a starting point, eg:
> 
> * enter
> * alt (meta)
> * shift
> * ctrl
> * "arrow keys": up, right, down, left
> * escape
> * backspace
> * tab
> * space
> * delete
> * F1-12
> 
> perhaps also
> 
> * help
> * page up / down
> * command-key (Mac)
> [etc?]
> 
> It would need to be discussed what people need: Emacs user, Vim users, etc.
> 
> In Vim for example,
>    :help key-notation
> brings
>    http://vim.sourceforge.net/htmldoc/intro.html#key-notation
> 
> 
> > Were you thinking of an enumerated list of values
> > for an attribute on keycap?
> 
> 
> The syntax may be best figured out by people like you, who are very 
> familiar with the DocBook language.
> 
> But I like your suggestion. What name would you suggest?
> 
>    <keycap function="shift">[shift]</keycap>
> 
> where the content of the element is the suggested default ASCII 
> rendering. But also allow for empty elements:
> 
>    <keycap function="shift"/>
> 
> so that
> 
>    <keycombo action="simul">
>      <keycap function="control">
>      <keycap>h</keycap>
>    </keycombo>
> 
> Pure semantics, no rendering info. The transformer/renderer can then 
> provide a default rendering (eg pics, ASCII), and the customizer can 
> override it.
> 
> Or a new element
> 
>    <input type="shift"/>
> 
> ... since some people use other means than keyboard to enter input.
> 
> 
> Tobi
> 
> 
> -- 
> http://www.pinkjuice.com/
> 

-- 

Bob Stayton                                 400 Encinal Street
Publications Architect                      Santa Cruz, CA  95060
Technical Publications                      voice: (831) 427-7796
The SCO Group                               fax:   (831) 429-1887
                                            email: bobs@sco.com



On Wed, Mar 05, 2003 at 03:05:31AM +0100, Florian Brunner wrote:
> Am Samstag, 1. Mdrz 2003 22.58 schrieb Henrik Motakef:
> > Florian Brunner <fbrunnerlist@gmx.ch> writes:
> > > The layout of the header and footer of
> > > these pages should be the same for all of them, just the links do change.
> > > So I would like to specify the header and footer at a single place with
> > > parameters to configure them. 
> >
> > This is definitly possible. There are XSL stylesheets to generate a
> > bunch of HTML files from Docbook, including a ToC, an index etc., and
> > they are faily customizable.
> >
> 
> Can you give me an example how to inline a file (eg. defining the header) with 
> parameters? I couldn't find one up to now.

It can't be done with just stylesheet parameters
in the stock DocBook stylesheets.
It requires a stylesheet customization file
containing a custom XSL template.  See:

http://www.sagehill.net/xml/docbookxsl/HtmlCustomEx.html#HTMLHeaders

You should look at the Website extension to DocBook.
It lets you set static links and images in headers and
footers with parameters in a configuration file.
But it assumes you are writing individual web pages,
not books.  See:

http://www.sagehill.net/xml/docbookxsl/PreCustom.html#Website

-- 

Bob Stayton                                 400 Encinal Street
Publications Architect                      Santa Cruz, CA  95060
Technical Publications                      voice: (831) 427-7796
The SCO Group                               fax:   (831) 429-1887
                                            email: bobs@sco.com



Jirka Kosek wrote:

 > Well you have proposed using HTML tables in their own namespaces.

This could be one way to incorporate the table model; each of the 
various ways has it's own pro/con balance. I'd be OK with several 
different ways.

 > You will either need to prefix all HTML table elements and you
 > wouldn't be then able to cut'n'paste from HTML.

It's trivial to cut and paste, then add the prefix via search and 
replace, eg

   :%s/<\(\/\?\)tr\(\_s*\)/<\1h:tr\2/g

etc, then cut and paste into DocBook (or do via some tiny script you can 
run each time). But c'n'p is not the most important reason for inclusion 
anyways, from my POV.

 > <html:table xmlns:html="http://www.w3.org/1999/xhtml">
 >   <html:tr>
 >     <html:td>Cell with <emphasis>emphasized words</emphasis></html:td>
 >   </html:tr>
 > </html:table>

   xmlns:h="http://www.w3.org/1999/xhtml"
can be set on the root element and/or be set (via "fixed") from the DTD. 
(see the SVG DTD)

Then write:

<h:table>
   <h:tr>
     <h:td>Cell with <emphasis>emphasized words</emphasis></html:td>
   </h:tr>
</h:table>

[... default ns example ...]

 > Which style from these two did you preffer?  Or do you have any other
 > solution which won't be as complex?

Prefixing each element might be one way offering most control from the 
DTD, but I'd be OK with any of the ways you showed.

Tobi

-- 
http://www.pinkjuice.com/




Tobias Reif wrote:

> It's trivial to cut and paste, then add the prefix via search and
> replace, eg
> 
>    :%s/<\(\/\?\)tr\(\_s*\)/<\1h:tr\2/g
> 
> etc, then cut and paste into DocBook (or do via some tiny script you can
> run each time). But c'n'p is not the most important reason for inclusion
> anyways, from my POV.

I though that this was point (maybe not yours, but othres who proposed
HTML tables in DocBook) -- allow easy reuse of existing tables in HTML
and make easier to type tables in DocBook for peoples who know HTML. I
think that learning CALS model is for "common user" easier than learn
how to use regexps to add namespace prefix.
 
>  > <html:table xmlns:html="http://www.w3.org/1999/xhtml">
>  >   <html:tr>
>  >     <html:td>Cell with <emphasis>emphasized words</emphasis></html:td>
>  >   </html:tr>
>  > </html:table>
> 
>    xmlns:h="http://www.w3.org/1999/xhtml"
> can be set on the root element and/or be set (via "fixed") from the DTD.
> (see the SVG DTD)

Fixed attributes can save typing but in a log term this practice won't
be suitable. Fixed attributes modify infoset and forces you to read
DTD/WXS when you want to process your document. Modern schema languages
like RNG even doesn't support this feature. But yes, meanwhile #FIXED is
a nice trick how to save typing. BTW I'm wondering what will happen to
XLink when people will start using schema languages without fixed
feature.

					Jirka

-- 
-----------------------------------------------------------------
  Jirka Kosek  	                     
  e-mail: jirka@kosek.cz
  http://www.kosek.cz



Sorry, Norm wanted to see hundreds jump in here. I'll just try it with 
my own two feet.

I see major usability, compatibility and support issues turning up with 
this discussion. What Tobias sees as trivial with respect to scripting 
and regular expression search and replace is simply a non-starter when 
it comes to a (somewhat recalcitrant) team of tech writers who are 
hanging on by both their toe and finger nails to the rocket-science of 
structured editing. It's hard enough to convince some folks that looking 
at element/tag names in the editor is not a major incovenience, 
complexification.

I've followed this discussion off and on and I'm running out of time, 
energy and patience. If we could have one or two detailed, concrete and 
preferably practicable alternative solutions to the dual-Table-model 
question, perhaps we could cut to the chase and begin some sort of 
definitive decision process going forward to the TC?

Thanks.                 ...edN

Tobias Reif wrote:
> Jirka Kosek wrote:
> 
>  > Well you have proposed using HTML tables in their own namespaces.
> 
> This could be one way to incorporate the table model; each of the 
> various ways has it's own pro/con balance. I'd be OK with several 
> different ways.
> 
>  > You will either need to prefix all HTML table elements and you
>  > wouldn't be then able to cut'n'paste from HTML.
> 
> It's trivial to cut and paste, then add the prefix via search and 
> replace, eg
> 
>   :%s/<\(\/\?\)tr\(\_s*\)/<\1h:tr\2/g
> 
> etc, then cut and paste into DocBook (or do via some tiny script you can 
> run each time). But c'n'p is not the most important reason for inclusion 
> anyways, from my POV.
> 
>  > <html:table xmlns:html="http://www.w3.org/1999/xhtml">
>  >   <html:tr>
>  >     <html:td>Cell with <emphasis>emphasized words</emphasis></html:td>
>  >   </html:tr>
>  > </html:table>
> 
>   xmlns:h="http://www.w3.org/1999/xhtml"
> can be set on the root element and/or be set (via "fixed") from the DTD. 
> (see the SVG DTD)
> 
> Then write:
> 
> <h:table>
>   <h:tr>
>     <h:td>Cell with <emphasis>emphasized words</emphasis></html:td>
>   </h:tr>
> </h:table>
> 
> [... default ns example ...]
> 
>  > Which style from these two did you preffer?  Or do you have any other
>  > solution which won't be as complex?
> 
> Prefixing each element might be one way offering most control from the 
> DTD, but I'd be OK with any of the ways you showed.
> 
> Tobi
> 





Jirka Kosek wrote:

 > I though that this was point (maybe not yours, but othres who proposed
 > HTML tables in DocBook) -- allow easy reuse of existing tables in HTML
 > and make easier to type tables in DocBook for peoples who know HTML.

One of the points, yes.

 > I
 > think that learning CALS model is for "common user" easier than learn
 > how to use regexps to add namespace prefix.

As I said, you can also use any other automatic tool or do it by hand. 
But obviously, this is one of the drawbacks of using prefixes. As I 
said, each of the different possibilities has its own pro/con balance; 
but each would be OK IMHO. When someone sees copy'n'paste as most 
important, then it's obviously best to not use prefixes.

 >>   xmlns:h="http://www.w3.org/1999/xhtml"
 >>can be set on the root element and/or be set (via "fixed") from the
 >>DTD.
 >>(see the SVG DTD)
 >>
 > Fixed attributes can save typing but in a log term this practice won't
 > be suitable. Fixed attributes modify infoset and forces you to read
 > DTD/WXS when you want to process your document.

Just above, I wrote

"xmlns:h="http://www.w3.org/1999/xhtml"
can be set on the root element and/or be set (via "fixed") from the 
DTD." (there's an "or")

Set it explicitly, in the document, eg on the root element.

 >Modern schema languages
 > like RNG even doesn't support this feature. But yes, meanwhile #FIXED
 > is
 > a nice trick how to save typing. BTW I'm wondering what will happen to
 > XLink when people will start using schema languages without fixed
 > feature.

See above.

Tobi

-- 
http://www.pinkjuice.com/





>/ Jirka Kosek <jirka@kosek.cz> was heard to say:
>| P.S. For everyone else: I know that this discussion is getting quite
>| tedious, but at least TC will have some input from users. Which is not
>| case for all issues. :-(

In that case, simplicity is a virtue. DocBook should have exactly one 
table model. Two is one too many. I vote for keeping the one we have. 
When I wrote my last book the style sheets seemed to do a more than 
adequate job of converting the CALS tables to HTML.
-- 

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|           Processing XML with Java (Addison-Wesley, 2002)          |
|              http://www.cafeconleche.org/books/xmljava             |
| http://www.amazon.com/exec/obidos/ISBN%3D0201771861/cafeaulaitA  |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://www.cafeaulait.org/      |
|  Read Cafe con Leche for XML News: http://www.cafeconleche.org/    |
+----------------------------------+---------------------------------+



Hi Norm


> But the truth of the matter is, I'm not sure this information is worth
> marking up in this level of detail. I'd probably use something much simpler.


I think that it's great if there's the possibility to do it in a simple 
way, but also go with very granular and detailed markup if that's needed.


> What if you want to do something more interesting, like test your
> source to make sure the quick reference includes all the keyboard
> commands actually used.


This requires that the testing tools knows what markup to expect for 
control, alt, etc. Otherwise, it has to be told that in this document, 
"Ctrl" stands for control input, but in this other doc, "C" stands for 
control input. As soon as this tool gets fed a third document, it might 
not work, since it might use "Strg".


> Well, I think I'd be tempted to recognize <keycap>Ctrl</keycap>


What if authors used "C-" (Emacs notation) or "Strg" (German key label) 
or "<C->" (Vim notation)? What if this tool is to be general, and has 
gets fed something other than <keycap>Ctrl</keycap> for control?

> and
> translate it directly into another language without adding more markup
> to make it more "semantic".


I see the latter as necessity. DocBook is mostly (should be 100% IMHO) 
about nothing but about being semantic. If I could markup input as 
input, instead of making up some ASCII rendering, or typing what's 
written on my keyboard, then that would add a lot of semantics, allowing 
for much more flexible processing:

In my transformation layer, I could then specify the rendering; provide 
pics of keycaps, or choose different ASCII renderings, translations, 
abbreviations or expansions (depending on the target audience), etc.

Tobi

-- 
http://www.pinkjuice.com/




-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 05 March 2003 06:58 am, Elliotte Rusty Harold wrote:
> >/ Jirka Kosek <jirka@kosek.cz> was heard to say:
> >| P.S. For everyone else: I know that this discussion is getting quite
> >| tedious, but at least TC will have some input from users. Which is not
> >| case for all issues. :-(
>
> In that case, simplicity is a virtue. DocBook should have exactly one
> table model. Two is one too many. I vote for keeping the one we have.
> When I wrote my last book the style sheets seemed to do a more than
> adequate job of converting the CALS tables to HTML.

While I like HTML tables, I tend to agree on this point. DocBook isn't 
XHTML, and that's OK. If we're going to move to XHTML tables, we should do 
it wholesale and depricate CALS tables. Obviously, this isn't an option, so 
I think that XHTML tables aren't really an option at this point either.

The co-existance problem can look simple in some trivial cases, but it gets 
messy in a hurry unless each shared element type has a mode attribute 
assigned to it (in which case, we're no better off than with namespace 
prefixes).

I'd love to be wrong about this, but I just don't see an elegant way to 
reconcile the two models without namespace prefixes (which are a 
non-starter for previously outlined reasons).

- -- 
Alex Russell
alex@netWindows.org
alex@SecurePipe.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+ZNfQoV0dQ6uSmkYRAuDDAKCoUMJG5vQk19yd5prF0DCIBSGp/ACfZN7b
BAJa8aBqE2aP7B+TUD89Ydc=
=LDb2
-----END PGP SIGNATURE-----




At 10:43 2003 03 04 -0600, Alex Russell wrote:

>The co-existance problem can look simple in some trivial cases, but it gets 
>messy in a hurry unless each shared element type has a mode attribute 
>assigned to it (in which case, we're no better off than with namespace 
>prefixes).
>
>I'd love to be wrong about this, but I just don't see an elegant way to 
>reconcile the two models without namespace prefixes (which are a 
>non-starter for previously outlined reasons).

See [1] for my summary analysis.  

(Note that when I use the notation such as html:table or cals:table, 
I am NOT suggesting that namespaces are to be used in the resulting DTD, 
I am merely using that notation as a convenience in my email to refer 
to logically different concepts.)

It is trivial for an application to tell if a properly marked up
table is either a CALS table or an HTML table with no namespaces
and no extra attributes.  

However, it is not possible for a DTD to prohibit markup that would 
be neither a valid CALS table nor a valid HTML table (i.e., a hybrid 
table).  Such can only be "prohibited" via a statement in the DocBook 
spec, not via a DTD.  (I don't see this as a problem.  There are lots 
of semantically invalid things you can do right now that the DTD cannot 
catch.  Such is the nature of DTDs.  But others feel otherwise.)

paul

[1] http://lists.oasis-open.org/archives/docbook-tc/200212/msg00003.html




>>>>> Tobias Reif <tobiasreif@pinkjuice.com>:

>    <keycombo action="simul">
>      <keycap function="control"/>
>      <keycap>h</keycap>
>    </keycombo>

When I read Bob Stayton's suggestion earlier in the thread, I thought
    <keycap function="control">h</keycap>
was what he meant...?

But of course that would make it hard to express something like C-M-h.

Perhaps one could do something like this...?
    <keycap function="control;meta">h</keycap>




Steinar Bang wrote:


>>   <keycombo action="simul">
>>     <keycap function="control"/>
>>     <keycap>h</keycap>
>>   </keycombo>
>>
> When I read Bob Stayton's suggestion earlier in the thread, I thought
>     <keycap function="control">h</keycap>
> was what he meant...?


I don't know what Bob meant, but the above is not a very clear way to 
describe the input action, IMHO.

The keycap element marks up the letter h, and the attribute is on that 
element; it is doesn't make much sense to say function="control"
would be an attribute of this keycap "h" (it isn't). XML attributes 
describe attributes of the element's meaning and optionally of it's content:

<rect color="red"/>

<filename class="headerfile">keyboard.h</filename>

But in your example

<keycap function="control">h</keycap>

the attribute is neither an attribute of the element, nor of it's 
content. The "h" doesn't or have the function "control".


> But of course that would make it hard to express something like C-M-h.
> 
> Perhaps one could do something like this...?
>     <keycap function="control;meta">h</keycap>


If you want to save typing, you could use some terse non-XML notation, 
then expand it to XML.

Here's the RFE:

http://sourceforge.net/tracker/index.php?func=detail&aid=697374&group_id=21935&atid=384107


Tobi


-- 
http://www.pinkjuice.com/

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Powered by ezmlm-idx