Menu
▾
▴
scrollkeeper-devel
|
From: Bob S. <bo...@sc...> - 2001-04-27 08:03:21
|
It sounds like the ScrollKeeper project needs to
work with OMF to settle these DTD issues. Kendall
responded, but is no longer working on OMF.
Do the SK developers already have a contact at
OMF to work with, or should I (or someone else)
initiate something? Through the ldp-meta mailing
list (which I'm on, but don't see much traffic)?
bobs
Bob Stayton 400 Encinal Street
Publications Architect Santa Cruz, CA 95060
Technical Publications voice: (831) 427-7796
The Santa Cruz Operation, Inc. fax: (831) 429-1887
email: bo...@sc...
|
|
From: Dan M. <da...@ea...> - 2001-04-27 09:49:23
|
On Fri, 27 Apr 2001, Bob Stayton wrote: > It sounds like the ScrollKeeper project needs to > work with OMF to settle these DTD issues. Kendall > responded, but is no longer working on OMF. > Do the SK developers already have a contact at > OMF to work with, or should I (or someone else) > initiate something? Through the ldp-meta mailing > list (which I'm on, but don't see much traffic)? I think Greg Leblanc is, in name, the active maintainer of the DTD now. I think he has some work to do ;) I think he's quietly lurking on both of these mailing lists. (Greg - are you here?) We definitely need to work with the OMF group more, not only on the DTD, but possibly on the OMF specification itself. I need to look over your emails in the last couple days more carefully to understand exactly what belongs in the OMF and what we consider as ScrollKeeper-specific extensions. BTW: I raised a handful of issues which seemed at the time to be inconsistancies and/or ambiguities in the spec and DTD on ldp-meta some time ago. I think those issues are still unresolved, and may be a good place to begin. I would recommend starting a thread on ldp-meta for each of the OMF elements to review whether the spec is complete, unambiguous, and that the DTD is consistant with the spec. Bob - Any help you can offer to help move things along would be appreciated :) Dan |
|
From: Eric B. <e.b...@no...> - 2001-04-27 10:19:10
|
Le Friday 27 April 2001 09:49, Dan Mueth a =E9crit : > > I think Greg Leblanc is, in name, the active maintainer of the DTD now.= I > think he has some work to do ;) I think he's quietly lurking on both o= f > these mailing lists. (Greg - are you here?) > > We definitely need to work with the OMF group more, not only on the DTD= , > but possibly on the OMF specification itself. I need to look over your > emails in the last couple days more carefully to understand exactly wha= t > belongs in the OMF and what we consider as ScrollKeeper-specific > extensions. > > BTW: I raised a handful of issues which seemed at the time to be > inconsistancies and/or ambiguities in the spec and DTD on ldp-meta some > time ago. I think those issues are still unresolved, and may be a good > place to begin. Speaking about this, one of the concerns at KDE was "how do we extract OM= F=20 data out of our docbook files?". We did not wish to store the OMF=20 meta-information in a separate file. So the idea so far is: - to automatically extract DocBook meta-information which has OMF equival= ent - to store OMF meta-information which has no DocBook equivalent (like the= =20 position in the categories tree) in the DocBook file, using XML namespace= to=20 differentiate it from plain DocBook, then to extract this information as = well. > I would recommend starting a thread on ldp-meta for each of the OMF > elements to review whether the spec is complete, unambiguous, and that = the > DTD is consistant with the spec. > > Bob - Any help you can offer to help move things along would be > appreciated :) > > Dan --=20 +----------------------------------------------------------------------+ | =C9ric Bischoff mailto:e.b...@no... = | +----------------------------------------------------------------------+ |
|
From: <las...@Su...> - 2001-04-27 10:31:23
|
> Speaking about this, one of the concerns at KDE was "how do we extract OMF > data out of our docbook files?". We did not wish to store the OMF > meta-information in a separate file. So the idea so far is: > - to automatically extract DocBook meta-information which has OMF equivalent > - to store OMF meta-information which has no DocBook equivalent (like the > position in the categories tree) in the DocBook file, using XML namespace to > differentiate it from plain DocBook, then to extract this information as well. > I think some support for automatic extraction from DocBook has been discussed on ldp-meta and even something has been implemented. It is called db2omf, the author says it has been added to the CVS, but I couldnt find it. You might want to check their web site, mailing list and get in contact with the author. The OMF web site and mailing list is available from scrollkeeper.sourceforge.net. Laszlo |
|
From: Dan M. <da...@ea...> - 2001-04-27 10:46:30
|
On Fri, 27 Apr 2001, Eric Bischoff wrote: > Speaking about this, one of the concerns at KDE was "how do we extract OMF > data out of our docbook files?". We did not wish to store the OMF > meta-information in a separate file. So the idea so far is: > - to automatically extract DocBook meta-information which has OMF equivalent > - to store OMF meta-information which has no DocBook equivalent (like the > position in the categories tree) in the DocBook file, using XML namespace to > differentiate it from plain DocBook, then to extract this information as well. In the long term, I think we want to have the OMF elements added to DocBook. (You may recall that Norman Walsh thought this was a good idea at the O'Reilly Summit.) This way authors would only maintain one file. For the sake of maintaining databases and such, we may still generate OMF files, but that is not of significance to the document authors. Before we can do this right, we have to stablize ScrollKeeper and the OMF DTD to some extent. Then we need to have the new tags added to DocBook. This takes a while, so I was planning on just using seperate OMF files in the interim. Your suggestion of adding tags which have their own namespace inside of a DocBook document is interesting. If we did this, would the document still be a valid DocBook document which can be parsed by any standard DocBook tool? My impression was that it would not, but you know much more about this than I do. Or perhaps I am misundestanding what you mean. Dan |
|
From: Eric B. <e.b...@no...> - 2001-04-27 11:49:46
|
Le Friday 27 April 2001 10:46, Dan Mueth a =E9crit : > On Fri, 27 Apr 2001, Eric Bischoff wrote: > > Speaking about this, one of the concerns at KDE was "how do we extrac= t > > OMF data out of our docbook files?". We did not wish to store the OMF > > meta-information in a separate file. So the idea so far is: > > - to automatically extract DocBook meta-information which has OMF > > equivalent - to store OMF meta-information which has no DocBook > > equivalent (like the position in the categories tree) in the DocBook > > file, using XML namespace to differentiate it from plain DocBook, the= n to > > extract this information as well. > > In the long term, I think we want to have the OMF elements added to > DocBook. (You may recall that Norman Walsh thought this was a good ide= a > at the O'Reilly Summit.)=20 Sure, but ScrollKeeper is becoming a reality now, so we need at least a=20 transitory solution. Furthermore, some people might not be able to switch= =20 immediately to latest DocBook version when OMF tags will be available, if= =20 ever. > This way authors would only maintain one > file. For the sake of maintaining databases and such, we may still > generate OMF files, but that is not of significance to the document > authors. Sure. But if we use OMF tags with namespace, transition to=20 DocBook-with-OMF-tags will probably be easy when it will be available. > Before we can do this right, we have to stablize ScrollKeeper and the O= MF > DTD to some extent. Then we need to have the new tags added to > DocBook. This takes a while, so I was planning on just using seperate > OMF files in the interim. The problem with external files is that it adds a risk of unsynchronizati= on=20 with main file, needs you to open twice in your editor, needs the transla= tors=20 to copy the external file, etc... Nothing very serious, but still adding=20 complexity while doc writers and translators are busy enough already. If = we=20 can spare them this effort, I feel it will be welcome. > Your suggestion of adding tags which have their own namespace inside of= a > DocBook document is interesting. If we did this, would the document st= ill > be a valid DocBook document which can be parsed by any standard DocBook > tool? ... and if yes, will the OMF tags be validated inside of their own DTD? We are exactly investigating those topics right now at KDE. I'll keep you= =20 informed of the results. For the moment I'm very ignorant about namespace= =20 issues. Maybe Norm knows more than us about this, after all he already investigat= ed=20 issues like DocBook + MathML inclusions. > My impression was that it would not, but you know much more about > this than I do. Or perhaps I am misundestanding what you mean. No, you understood perfectly. My opinion is that it will work, but only a= =20 real-life test will be able to tell us the truth ;-). Also, if it does no= t=20 work, nothing prevents us from preprocessing the "merged" file to separat= e=20 the DocBook on one side from the OMF on the other side ;-). --=20 +----------------------------------------------------------------------+ | =C9ric Bischoff mailto:e.b...@no... = | +----------------------------------------------------------------------+ |
|
From: <las...@Su...> - 2001-04-27 11:56:57
|
> No, you understood perfectly. My opinion is that it will work, but only= a > real-life test will be able to tell us the truth ;-). Also, if it does = not > work, nothing prevents us from preprocessing the "merged" file to separ= ate > the DocBook on one side from the OMF on the other side ;-). This separation could be done by Scrollkeeper. Stylesheet or libxml based solution could be implemented. I wonder if you could still turn these files (the not separated ones) to HTML with the tools that are usually used for this (I dont know if this is an issue). L=E1szl=F3 |
|
From: Norman W. <nd...@nw...> - 2001-04-27 12:46:11
|
I tried to get the OFM DTD today, but without success: http://www.ibiblio.org/cgi-bin/cvsweb.cgi/ contains only CVSROOT The web page doesn't indicate what password works for cvs -d :pserver:ano...@ww...:/osrt/omf/cvsroot login and http://www.ibiblio.org/pub/Linux/metadata/OMF.dtd is the DTD, but the ancillary modules countryCodes.mod, licenseTypes.mod, etc. aren't present. (OTOH, they aren't actually referenced in OMF.dtd so maybe that isn't an issue...) Be seeing you, norm -- Norman Walsh <nd...@nw...> | So, are you working on finding that bug http://nwalsh.com/ | now, or are you leaving it until later? | Yes. |
|
From: <las...@Su...> - 2001-04-27 12:53:26
|
Norman Walsh wrote: > = > I tried to get the OFM DTD today, but without success: > = > http://www.ibiblio.org/cgi-bin/cvsweb.cgi/ contains only CVSROOT > = > The web page doesn't indicate what password works for > = > cvs -d :pserver:ano...@ww...:/osrt/omf/cvsroot login > = I just checked the CVS and saw it was completely empty. I am pretty sure their has been some discussion on ldp-meta about this and several files were mentioned as already added to the CVS. Strange ... L=E1szl=F3 |
|
From: Frederik F. <fo...@Co...> - 2001-04-27 14:21:19
|
I found this, but it doesn't seem to be terribly recent http://casbah.org/cgi-bin/cvsweb.cgi/XML/DTDs/OMF/ (and contains a few things which I don't see how they can be used in a syntactically valid way in XML). -- Frederik Fouvry - fo...@co... KDE DocBook Team - kde...@ma... |
|
From: Kendall C. <kc...@nt...> - 2001-04-27 14:47:51
|
On Fri, Apr 27, 2001 at 04:21:09PM +0200, Frederik Fouvry wrote: > > I found this, but it doesn't seem to be terribly recent > > http://casbah.org/cgi-bin/cvsweb.cgi/XML/DTDs/OMF/ > > (and contains a few things which I don't see how they can be used > in a syntactically valid way in XML). I just sent the latest version of the OMF DTD *I have* to the SK list. The version in Casbah CVS is very old and needs to be pulled. It shouldn't be pointed to by the OMF site, if it is. Best, Kendall Clark PS--Thanks for publicly pointing out my bugs in a DTD that's *15* months old and which no one should be using! :> |
|
From: Paul J. <pj...@me...> - 2001-04-27 15:12:13
|
folks, none of the discussion of the OMF and the problems accessing it have gotten to the OMF list (which has been quiet for quite a while). i'm cross-posting this note so some folks on the list can see a little of what's going on here. i don't know what happened with the cvs tree for the DTD. i suspect there was a communications break between kendall and jim ray on this one. i too understood that the latest version would be on ibiblio and that we had gotten it from kendall with his blessing some time back. somehow i also thought that Eric Bischoff was keeping it now (with kendall's blessing). i agree with kendall, implicitly, that the OMF should be taken as a strong, but rough, draft and that the real world implementation experience should help to form it into a more useful and practical DTD. jim ray is out of town just now so it may be monday before i can get the cvs status cleared. please be patient tho; i'm aware of your needs and will see that we get some action as quickly as i can. On 27 Apr 2001, Norman Walsh wrote: +I tried to get the OFM DTD today, but without success: + + http://www.ibiblio.org/cgi-bin/cvsweb.cgi/ contains only CVSROOT + +The web page doesn't indicate what password works for + + cvs -d :pserver:ano...@ww...:/osrt/omf/cvsroot login + +and + + http://www.ibiblio.org/pub/Linux/metadata/OMF.dtd + +is the DTD, but the ancillary modules countryCodes.mod, licenseTypes.mod, +etc. aren't present. (OTOH, they aren't actually referenced in OMF.dtd +so maybe that isn't an issue...) + + Be seeing you, + norm + + ========================================================================== Paul Jones "Gort! Klaatu barada nikto!" http://www.ibiblio.org/pjones/ at the Site Formerly Known As MetaLab.unc.edu pj...@ib... voice: (919) 962-7600 fax: (919) 962-8071 =========================================================================== |
|
From: Eric B. <e.b...@no...> - 2001-04-27 15:32:18
|
Le Friday 27 April 2001 17:11, Paul Jones a =E9crit : > folks, > none of the discussion of the OMF and the problems accessing it have > gotten to the OMF list (which has been quiet for quite a while). i'm > cross-posting this note so some folks on the list can see a little of > what's going on here. > i don't know what happened with the cvs tree for the DTD. i suspect the= re > was a communications break between kendall and jim ray on this one. i t= oo > understood that the latest version would be on ibiblio and that we had > gotten it from kendall with his blessing some time back. somehow i also > thought that Eric Bischoff was keeping it now (with kendall's blessing). Uh? I never had anything to do wiith OMF. I haven't even downloaded the D= TD=20 yet ;-). You must be mixing me with somebody else. It's enough that I dai= ly=20 get messages asking me about the World Convention of Wrestling ;-). > i > agree with kendall, implicitly, that the OMF should be taken as a stron= g, > but rough, draft and that the real world implementation experience shou= ld > help to form it into a more useful and practical DTD. > jim ray is out of town just now so it may be monday before i can get th= e > cvs status cleared. please be patient tho; i'm aware of your needs and > will see that we get some action as quickly as i can. --=20 +----------------------------------------------------------------------+ | =C9ric Bischoff mailto:e.b...@no... = | +----------------------------------------------------------------------+ |
|
From: Paul J. <pj...@me...> - 2001-04-27 15:35:19
|
please see my correction which was immediately send after my mistake
naming you. sorry to have caused confusion. again not "eric as mentioned
by kendall" but "Greg Leblanc as mentioned by Dan"
sorry for the confusion
==========================================================================
Paul Jones
"Gort! Klaatu barada nikto!"
http://www.ibiblio.org/pjones/ at the Site Formerly Known As MetaLab.unc.edu
pj...@ib... voice: (919) 962-7600 fax: (919) 962-8071
===========================================================================
|
|
From: Eric B. <e.b...@no...> - 2001-04-27 15:40:18
|
Le Friday 27 April 2001 17:35, Paul Jones a =E9crit : > please see my correction which was immediately send after my mistake > naming you. sorry to have caused confusion. again not "eric as mentione= d > by kendall" but "Greg Leblanc as mentioned by Dan" > sorry for the confusion Yeah, I saw the correction right after posting, sorry. Well, I hope that mentioning Eric Bischoff from the WCW made people smile= a=20 bit ;-) --=20 +----------------------------------------------------------------------+ | =C9ric Bischoff mailto:e.b...@no... = | +----------------------------------------------------------------------+ |
|
From: Norman W. <nd...@nw...> - 2001-04-27 12:48:54
|
The OMF DTD also has some odd looking content models:
<!ELEMENT resource (creator, maintainer, contributor, title,
date, versionGroup, subject, description,
type, format, identifier, source, language,
relation, coverage, rights)* >
That suggests that a resource can have zero or more occurrences of
the entire sequence (creator, maintainer, ... coverage, rights). Is
that what was intended? Or did you mean (creator|maintainer|...|rights)*?
Be seeing you,
norm
--
Norman Walsh <nd...@nw...> | If you are losing your leisure, look
http://nwalsh.com/ | out! You may be losing your
| soul.--Logan Pearshall Smith
|
|
From: Norman W. <nd...@nw...> - 2001-04-27 12:52:50
|
/ Eric Bischoff <e.b...@no...> was heard to say:
| > Your suggestion of adding tags which have their own namespace inside of a
| > DocBook document is interesting. If we did this, would the document still
| > be a valid DocBook document which can be parsed by any standard DocBook
| > tool?
No.
| ... and if yes, will the OMF tags be validated inside of their own DTD?
Nope.
| Maybe Norm knows more than us about this, after all he already investigated
| issues like DocBook + MathML inclusions.
If we build a single DTD that combines DocBook and OMF, then documents
can be validated against that.
Be seeing you,
norm
--
Norman Walsh <nd...@nw...> | To create a little flower is the labour
http://nwalsh.com/ | of ages.--Blake
|
|
From: Eric B. <e.b...@no...> - 2001-04-27 13:09:56
|
Le Friday 27 April 2001 14:52, Norman Walsh a =E9crit : > | > Your suggestion of adding tags which have their own namespace insid= e of > | > a DocBook document is interesting. If we did this, would the docum= ent > | > still be a valid DocBook document which can be parsed by any standa= rd > | > DocBook tool? > > No. Even when providing and declaring the OMF DTD from the document? > | ... and if yes, will the OMF tags be validated inside of their own DT= D? > > Nope. > > | Maybe Norm knows more than us about this, after all he already > | investigated issues like DocBook + MathML inclusions. > > If we build a single DTD that combines DocBook and OMF, then documents > can be validated against that. This of course would be great. But still, in the Duck book, it is said somewhere that some MathML tagged= =20 data can be included in a DocBook file. It's basically the same problem, = and=20 as far as I know, the MathML tags haven't been merged with the DocBook DT= D.=20 What is the point I don't understand? --=20 +----------------------------------------------------------------------+ | =C9ric Bischoff mailto:e.b...@no... = | +----------------------------------------------------------------------+ |
|
From: Norman W. <nd...@nw...> - 2001-04-27 13:16:46
|
/ Eric Bischoff <e.b...@no...> was heard to say:
| Le Friday 27 April 2001 14:52, Norman Walsh a écrit :
| > | > Your suggestion of adding tags which have their own namespace inside of
| > | > a DocBook document is interesting. If we did this, would the document
| > | > still be a valid DocBook document which can be parsed by any standard
| > | > DocBook tool?
| >
| > No.
|
| Even when providing and declaring the OMF DTD from the document?
Well, it would depend how you did that. As long as you build a
complete set of declarations, it would parse just fine. You could do
that with the internal subset, but making a separate DTD that combines
OMF and DocBook is probably the way to go.
| > If we build a single DTD that combines DocBook and OMF, then documents
| > can be validated against that.
|
| This of course would be great.
I think that's probably the course to pursue.
| But still, in the Duck book, it is said somewhere that some MathML tagged
| data can be included in a DocBook file. It's basically the same problem, and
| as far as I know, the MathML tags haven't been merged with the DocBook DTD.
| What is the point I don't understand?
You can only validate a DocBook+MathML file when you do use a merged DTD.
Be seeing you,
norm
P.S. I've now subscribed to scrollkeeper-devel and ldp-meta.
--
Norman Walsh <nd...@nw...> | To the man who is afraid everything
http://nwalsh.com/ | rustles.--Sophocles
|