Menu
▾
▴
scrollkeeper-devel — Developer discussion list for ScrollKeeper
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(5) |
Oct
(50) |
Nov
(117) |
Dec
(38) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(7) |
Feb
(7) |
Mar
(40) |
Apr
(83) |
May
(72) |
Jun
(15) |
Jul
(8) |
Aug
(1) |
Sep
(29) |
Oct
|
Nov
(6) |
Dec
(4) |
| 2002 |
Jan
(8) |
Feb
(4) |
Mar
(18) |
Apr
(27) |
May
(70) |
Jun
(21) |
Jul
(13) |
Aug
(27) |
Sep
(2) |
Oct
(26) |
Nov
(1) |
Dec
(6) |
| 2003 |
Jan
(17) |
Feb
(9) |
Mar
(4) |
Apr
(14) |
May
(18) |
Jun
(25) |
Jul
(4) |
Aug
(11) |
Sep
(14) |
Oct
(6) |
Nov
(5) |
Dec
(22) |
| 2004 |
Jan
(16) |
Feb
(3) |
Mar
(7) |
Apr
(2) |
May
(4) |
Jun
|
Jul
(3) |
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2005 |
Jan
|
Feb
|
Mar
(5) |
Apr
(1) |
May
(3) |
Jun
(2) |
Jul
(5) |
Aug
(2) |
Sep
(2) |
Oct
(3) |
Nov
(7) |
Dec
(6) |
| 2006 |
Jan
(3) |
Feb
(3) |
Mar
(1) |
Apr
(2) |
May
(6) |
Jun
(21) |
Jul
(12) |
Aug
(7) |
Sep
(10) |
Oct
(34) |
Nov
(21) |
Dec
(28) |
| 2007 |
Jan
(29) |
Feb
(39) |
Mar
(25) |
Apr
(39) |
May
(26) |
Jun
(12) |
Jul
(16) |
Aug
(42) |
Sep
(24) |
Oct
(11) |
Nov
(8) |
Dec
(6) |
| 2008 |
Jan
(10) |
Feb
(9) |
Mar
(30) |
Apr
(19) |
May
(16) |
Jun
(10) |
Jul
(27) |
Aug
(22) |
Sep
(23) |
Oct
(18) |
Nov
(21) |
Dec
(51) |
| 2009 |
Jan
(56) |
Feb
(39) |
Mar
(45) |
Apr
(49) |
May
(108) |
Jun
(109) |
Jul
(66) |
Aug
(33) |
Sep
(26) |
Oct
(41) |
Nov
(13) |
Dec
(14) |
| 2010 |
Jan
(6) |
Feb
(7) |
Mar
(36) |
Apr
(50) |
May
(74) |
Jun
(61) |
Jul
(33) |
Aug
(58) |
Sep
(29) |
Oct
|
Nov
(1) |
Dec
|
| 2011 |
Jan
(1) |
Feb
(2) |
Mar
(3) |
Apr
(1) |
May
(1) |
Jun
(2) |
Jul
(2) |
Aug
(1) |
Sep
(1) |
Oct
(3) |
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
|
May
(2) |
Jun
|
Jul
(1) |
Aug
(2) |
Sep
(2) |
Oct
(2) |
Nov
|
Dec
|
| 2014 |
Jan
(3) |
Feb
|
Mar
(3) |
Apr
(1) |
May
(1) |
Jun
|
Jul
(2) |
Aug
|
Sep
(6) |
Oct
(6) |
Nov
(5) |
Dec
(1) |
| 2015 |
Jan
(2) |
Feb
(3) |
Mar
(2) |
Apr
(1) |
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
(2) |
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(3) |
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
(1) |
Mar
(2) |
Apr
(3) |
May
|
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(3) |
Oct
(1) |
Nov
|
Dec
(2) |
| 2019 |
Jan
(1) |
Feb
(2) |
Mar
(3) |
Apr
|
May
(1) |
Jun
(4) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(3) |
Dec
|
| 2020 |
Jan
(2) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
(1) |
Nov
|
Dec
(1) |
| 2021 |
Jan
|
Feb
(2) |
Mar
(6) |
Apr
(4) |
May
(3) |
Jun
(2) |
Jul
(5) |
Aug
(18) |
Sep
(13) |
Oct
(19) |
Nov
(35) |
Dec
(23) |
| 2022 |
Jan
(6) |
Feb
(10) |
Mar
(6) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
(2) |
Oct
(1) |
Nov
|
Dec
|
| 2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(1) |
Nov
(1) |
Dec
|
| 2024 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
(2) |
Nov
|
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(1) |
Aug
(1) |
Sep
(1) |
Oct
(1) |
Nov
(5) |
Dec
(4) |
| 2026 |
Jan
(1) |
Feb
(4) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <las...@Su...> - 2001-05-04 12:07:46
|
Norman Walsh wrote: > = > / L=E1szl=F3 Kov=E1cs <las...@Su...> was heard to say: > | the new XSL stylesheet based TOC extraction. libxml2 version 2.3.8 > | contains a DocBook SGML parser that creates a DOM tree from an SGML > | document. > = > From any SGML document, or just a DocBook document? How general is this= ? > Does it support tag omission, etc.? > = > Be seeing you, DocBook only. And I wouldnt think it is bug free. After using it for 2-3 days I have submitted about 3-4 patches about tags not being handled correctly. Also the encoding detection is a major problem. It doesnt seem to be possible for DocBook SGML files. I think the DcoBook SGML parser is just an intermediary solution, people would be expected to use DocBook XML for docs, not DocBook SGML. Laszlo |
|
From: Norman W. <nd...@nw...> - 2001-05-04 11:41:59
|
/ László Kovács <las...@Su...> was heard to say:
| the new XSL stylesheet based TOC extraction. libxml2 version 2.3.8
| contains a DocBook SGML parser that creates a DOM tree from an SGML
| document.
From any SGML document, or just a DocBook document? How general is this?
Does it support tag omission, etc.?
Be seeing you,
norm
--
Norman Walsh <nd...@nw...> | Everything the same; everything
http://nwalsh.com/ | distinct.
|
|
From: <las...@Su...> - 2001-05-04 10:30:10
|
Hello, I moved Scrollkeeper to libxml2, changes are in the CVS. It depends on the latest libxml2, this is 2.3.8. It also depends on libxslt as I added the new XSL stylesheet based TOC extraction. libxml2 version 2.3.8 contains a DocBook SGML parser that creates a DOM tree from an SGML document. This is very useful in order to apply XSL stylesheets to SGML docs (although it generates error messages if the source document is not good quality DocBook SGML). Scrollkeeper right now support DocBook SGML and DocBook XML documents in the same way. This is in CVS HEAD only at the moment, but a new release will be coming out soon. Laszlo |
|
From: Eric B. <e.b...@no...> - 2001-04-28 04:07:19
|
Le Friday 27 April 2001 19:03, Norman Walsh a =E9crit : > [I'm not sure what list this best belongs on. Forward at will.] > > In looking at OMF and the existing DocBook metadata, I observe that > there are some conflicts (title in OMF doesn't have the same content > model as the DocBook title element, person uses "firstName/lastName" > where DocBook would use "firstname/surname", etc.). > > So the first question I have is, which is more appealing to the > community developing OFM tools: getting OMF support into DocBook by > way of elements in a separate namespace The advantages of namespaces is modularity (avoiding DocBook to get bloat= ed).=20 But as it has been said here, there might be validation problems. > or by getting a joint > OMF/DocBook TC task force to harmonize things so that the OMF elements > would go directly into DocBook? Of course this would remove the semantic conflicts in a much stronger way. --=20 +----------------------------------------------------------------------+ | =C9ric Bischoff mailto:e.b...@no... = | +----------------------------------------------------------------------+ |
|
From: Paul J. <pj...@me...> - 2001-04-27 22:37:14
|
i agree with kendall here for the most part. any text project doing
metadata should ideally support the dublin core guidelines. to that extent
placing general support for the dublin core tags would be a great idea and
be a boon for docbook users. the less part now: dublin core is a great
guideline, but each implimentation tends to tweek it a bit, add its own
subfields, its own controlled vocabulary, etc. so an idea implimentation
might support the dublin core generally but allow for more specific tags
like the OMF as well.
==========================================================================
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: Dan M. <da...@ea...> - 2001-04-27 21:44:56
|
Forwarding to ldp-meta in an attempt to move the conversation to that list... ---------- Forwarded message ---------- Date: Fri, 27 Apr 2001 15:59:53 -0500 From: Kendall Clark <ke...@mo...> To: Norman Walsh <nd...@nw...> Cc: scr...@li... Subject: [Scrollkeeper-devel] DocBook and OMF >>>>> "norman" == Norman Walsh <nd...@nw...> writes: norman> So the first question I have is, which is more appealing to norman> the community developing OFM tools: getting OMF support into norman> DocBook by way of elements in a separate namespace or by norman> getting a joint OMF/DocBook TC task force to harmonize norman> things so that the OMF elements would go directly into norman> DocBook? Speaking only for myself, how about a combination? That is, I'd like to see Dublin Core in DocBook and a way to put OMF's tweaks and additions to DC into DocBook via namespaces. In other words, OMF is *largely* based on Dublin Core. It seems to me to make more sense to integrate DC into DocBook first. Failing that, I'd like to see the task force approach, since that would mean *most* of Dublin Core had been integrated into DocBook, even if only by way of OMF. Best, Kendall Clark _______________________________________________ Scrollkeeper-devel mailing list Scr...@li... http://lists.sourceforge.net/lists/listinfo/scrollkeeper-devel |
|
From: Kendall C. <ke...@mo...> - 2001-04-27 21:00:10
|
>>>>> "norman" == Norman Walsh <nd...@nw...> writes: norman> So the first question I have is, which is more appealing to norman> the community developing OFM tools: getting OMF support into norman> DocBook by way of elements in a separate namespace or by norman> getting a joint OMF/DocBook TC task force to harmonize norman> things so that the OMF elements would go directly into norman> DocBook? Speaking only for myself, how about a combination? That is, I'd like to see Dublin Core in DocBook and a way to put OMF's tweaks and additions to DC into DocBook via namespaces. In other words, OMF is *largely* based on Dublin Core. It seems to me to make more sense to integrate DC into DocBook first. Failing that, I'd like to see the task force approach, since that would mean *most* of Dublin Core had been integrated into DocBook, even if only by way of OMF. Best, Kendall Clark |
|
From: Dan M. <da...@ea...> - 2001-04-27 19:34:59
|
I am forwarding Norman's email to the OMF list (ldp-meta), as I think this pertains specifically to the OMF specification and OMF DTD, more than to ScrollKeeper directly. Let's try to have this discussion on that list. BTW: Anybody who is actively involved in ScrollKeeper should probably join the OMF mailing list. You can do so here: http://franklin.oit.unc.edu/cgi-bin/lyris.pl?enter=ldp-meta Dan ---------- Forwarded message ---------- Date: 27 Apr 2001 13:03:27 -0400 From: Norman Walsh <nd...@nw...> To: scr...@li... Subject: [Scrollkeeper-devel] DocBook and OMF [I'm not sure what list this best belongs on. Forward at will.] In looking at OMF and the existing DocBook metadata, I observe that there are some conflicts (title in OMF doesn't have the same content model as the DocBook title element, person uses "firstName/lastName" where DocBook would use "firstname/surname", etc.). So the first question I have is, which is more appealing to the community developing OFM tools: getting OMF support into DocBook by way of elements in a separate namespace or by getting a joint OMF/DocBook TC task force to harmonize things so that the OMF elements would go directly into DocBook? Be seeing you, norm -- Norman Walsh <nd...@nw...> | This mortal life is a little thing, http://nwalsh.com/ | lived in a little corner of the earth; | and little, too, is the longest fame to | come--dependent as it is on a | succession of fast-perishing little men | who have no knowledge even of their own | selves, much less of one dead and | gone.--Marcus Aurelius _______________________________________________ Scrollkeeper-devel mailing list Scr...@li... http://lists.sourceforge.net/lists/listinfo/scrollkeeper-devel |
|
From: Norman W. <nd...@nw...> - 2001-04-27 17:03:36
|
[I'm not sure what list this best belongs on. Forward at will.]
In looking at OMF and the existing DocBook metadata, I observe that
there are some conflicts (title in OMF doesn't have the same content
model as the DocBook title element, person uses "firstName/lastName"
where DocBook would use "firstname/surname", etc.).
So the first question I have is, which is more appealing to the
community developing OFM tools: getting OMF support into DocBook by
way of elements in a separate namespace or by getting a joint
OMF/DocBook TC task force to harmonize things so that the OMF elements
would go directly into DocBook?
Be seeing you,
norm
--
Norman Walsh <nd...@nw...> | This mortal life is a little thing,
http://nwalsh.com/ | lived in a little corner of the earth;
| and little, too, is the longest fame to
| come--dependent as it is on a
| succession of fast-perishing little men
| who have no knowledge even of their own
| selves, much less of one dead and
| gone.--Marcus Aurelius
|
|
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: 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: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:13:59
|
i meant to say that i agree with dan that Greg Leblanc is the DTD keeper. sorry, eric. On Fri, 27 Apr 2001, Paul Jones wrote: +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 +=========================================================================== + + + +--- +You are currently subscribed to ldp-meta as: pj...@me... +To unsubscribe send a blank email to lea...@fr... + ========================================================================== 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: 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: 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: Kendall C. <ke...@mo...> - 2001-04-27 14:39:27
|
All,
Here's the latest version of the OMF DTD. I think I passed a version
similar to this to G. Leblanc for further maintenance, but it doesn't
seem to have gotten into OMF's CVS. I've added a 'uri' attribute as a
way to sort out the URL/URI confusion. (Issue needs further
discussion.)
I'm not including the entity sets I'd worked on, largely as an
experiment of my own, as the OMF team never discussed maintaining
formal vocabularies or what mechanism to use to do so. (I'll send
these to people off-list, but they're probably worthless at this
point. Hmm, I'll also note further that I don't remember OMF ever
making a distinction between the language of the *resource* and the
language of the OMF file itself. The language element is the language
of the resource; as for whether OMF files can be in languages other
than English, I don't know why not, in which case something like
xml:lang should be used.)
I also want to answer some of the off-list questions I've gotten.
As for why OMF didn't use RDF, there are two reasons.
First, the primary OMF deliverable is the written specification of
elements, not this XML DTD, the XML Schema I started sketching out at
the end of 2000, nor any other formal schema. Our view was that
projects like SK that were using OMF would best know which formal
schema tool to use. Now that there is a helpful (IMO) proliferation of
such tools, I think that view is a bit vindicated.
The second reason is purely biographical and historical; I thought
since early on that RDF was particularly fitting to OMF, but at the
time, there was no RDF schema language, there was no N3 RDF syntax,
and I knew more about DTDs than RDF anyway.
As for the entity sets, which were my way of trying to work on a
controlled vocabulary for some of the OMF values, they too were also
an experiment I did on my own, primarily by writing Python scripts to
turn ISO data files for country and language codes into XML entities,
as well as trying to stay on top of the mass of Linux (and, in truth,
not just Linux, but any OS that might use OMF: the BSDs, the
commercial Unixes, etc. ) distributions and free software licenses
that exist. Both of these require more active attention that I've had
to give, especially since they weren't being used as far as I know.
(The other, purely technical issue that I never really sorted out is
how the entity sets should be used, whether as parameter or general
entities, or as something else. This issue may well tip the scales
from XML DTD to one of the other, more contemporary schema tools that
provide some means for doing this more cleanly. One might look at the
NewsML stuff for inspiration; if I remember correctly, it or its
successors does something similar with its news topic sets.)
I suspect since SK has more people-power than OMF, one service that SK
could provide to the free software world is to be the place that
maintains controlled vocabularies for OS-distributions and free-open
software licenses. The language and country code vocabularies are, in
my view, essentially handled by ISO and just require some scriptage so
as to make maintenance as non-painful as possible.
Finally, please excuse my on-list reply to off-list questions; I've
just moved into a new old-house, have the wiring contractor due any
minute to spread the joy of cat5 throughout, and all my XML and SGML
books are packed and not handy for reference.
Best,
Kendall Clark
--
<?xml version="1.0"?>
<!--
Open Source Metadata Framework (OMF XML DTD) Version 1.1
Copyright (C) 1999, 2000, 2001 Kendall Grant Clark. All rights reserved.
$Id: OMF.dtd,v 1.4 2001/04/27 14:10:23 kclark Exp $
To use the OMF.dtd, an FPI like the following works:
"-//Open Source Metadata Framework //DTD OMF V1.1//EN"
Permission to use, copy, modify and distribute the OMF DTD and its
accompanying documentation for any purpose and without fee is hereby
granted in perpetuity, provided that the above copyright notice and
this paragraph appear in all copies. The copyright holders make no
representation about the suitability of the DTD for any purpose. It
is provided "as is" without expressed or implied warranty. If you
modify the OMF DTD in any way, except for declaring and referencing
additional sets of general entities, declaring additional notations,
please label your DTD as a variant of OMF. This license requirement is
stated solely in the interests of maintaining data interchange
capability.
-->
<!-- ............................................................. -->
<!-- Entity Sets ................................................. -->
<!-- ............................................................. -->
<!ENTITY % licenseTypes PUBLIC
"-//Open Source Metadata Framework (OMF)//ENTITIES License Types//EN"
"licenseTypes.mod" >
<!-- %licenseTypes; -->
<!ENTITY % countryCodes PUBLIC
"-//Open Source Metadata Framework (OMF)//ENTITIES Country Codes//EN"
"countryCodes.mod" >
<!-- %countryCodes; -->
<!ENTITY % languageCodes PUBLIC
"-//Open Source Metadata Framework (OMF)//ENTITIES Language Codes//EN"
"languageCodes.mod" >
<!-- %languageCodes; -->
<!ENTITY % linuxDistributions PUBLIC
"-//Open Source Metadata Framework (OMF)//ENTITIES Linux Distributions//EN"
"linuxDistributions.mod" >
<!-- %linuxDistributions; -->
<!-- ............................................................. -->
<!-- ............................................................. -->
<!-- ............................................................. -->
<!-- Internal Entities ........................................... -->
<!-- ............................................................. -->
<!ENTITY % base.attribute.set
"id ID #IMPLIED
modified CDATA #IMPLIED
created CDATA #IMPLIED" >
<!ENTITY % core.attribute.set
"%base.attribute.set;
agent CDATA #IMPLIED
status CDATA #IMPLIED" >
<!ENTITY % url.attribute.set
"url CDATA #REQUIRED
uri CDATA #IMPLIED
%core.attribute.set;" >
<!ENTITY % value.attribute.set
"value CDATA #REQUIRED
%core.attribute.set;" >
<!ENTITY % person.model
"(honorific* | firstName | otherName* | surname | email+)">
<!ENTITY % org.model
"(name+ | division* | email+)" >
<!ENTITY % content.entity.model
"(organization | person)*" >
<!-- ............................................................. -->
<!-- ............................................................. -->
<!-- ............................................................. -->
<!-- Element Declarations......................................... -->
<!-- ............................................................. -->
<!-- omf root element -->
<!ELEMENT omf (resource)+ >
<!ATTLIST omf
%base.attribute.set; >
<!-- resource -->
<!ELEMENT resource (creator
| maintainer
| contributor
| title
| date
| versionGroup
| subject
| description
| type
| format
| identifier
| source
| language
| relation
| coverage
| rights)* >
<!ATTLIST resource
%core.attribute.set; >
<!-- creator -->
<!ELEMENT creator
%content.entity.model; >
<!ATTLIST creator
%core.attribute.set; >
<!-- organization -->
<!ELEMENT organization
%org.model; >
<!-- name -->
<!ELEMENT name (#PCDATA) >
<!ATTLIST name
%core.attribute.set; >
<!-- division -->
<!ELEMENT division (#PCDATA) >
<!ATTLIST division
%core.attribute.set; >
<!-- person -->
<!ELEMENT person
%person.model; >
<!-- email -->
<!ELEMENT email (#PCDATA) >
<!ATTLIST email
%core.attribute.set; >
<!-- honorific -->
<!ELEMENT honorific (#PCDATA) >
<!ATTLIST honorific
%core.attribute.set; >
<!-- firstName -->
<!ELEMENT firstName (#PCDATA) >
<!ATTLIST firstName
%core.attribute.set; >
<!-- otherName -->
<!ELEMENT otherName (#PCDATA) >
<!ATTLIST otherName
%core.attribute.set; >
<!-- surname -->
<!ELEMENT surname (#PCDATA) >
<!ATTLIST surname
%core.attribute.set; >
<!-- maintainer -->
<!ELEMENT maintainer
%content.entity.model; >
<!ATTLIST maintainer
%core.attribute.set; >
<!-- contributor -->
<!ELEMENT contributor
%content.entity.model; >
<!ATTLIST contributor
%core.attribute.set; >
<!-- title -->
<!ELEMENT title (#PCDATA) >
<!ATTLIST title
%core.attribute.set; >
<!-- versiongroup -->
<!ELEMENT versionGroup (version)* >
<!ATTLIST versionGroup
%core.attribute.set; >
<!-- version -->
<!ELEMENT version (id | date | description?) >
<!ATTLIST version
%core.attribute.set; >
<!-- id -->
<!ELEMENT id (#PCDATA) >
<!ATTLIST id
%core.attribute.set; >
<!-- date -->
<!ELEMENT date (#PCDATA) >
<!ATTLIST date
%core.attribute.set; >
<!-- description -->
<!ELEMENT description (#PCDATA) >
<!ATTLIST description
%core.attribute.set; >
<!-- subject -->
<!ELEMENT subject (#PCDATA) >
<!ATTLIST subject
%core.attribute.set; >
<!-- type -->
<!ELEMENT type (#PCDATA) >
<!ATTLIST type
%core.attribute.set; >
<!-- format -->
<!ELEMENT format EMPTY >
<!ATTLIST format
mime CDATA #REQUIRED
dtd CDATA #IMPLIED
%core.attribute.set; >
<!-- identifier -->
<!ELEMENT identifier EMPTY >
<!ATTLIST identifier
%url.attribute.set; >
<!-- source -->
<!ELEMENT source (#PCDATA) >
<!ATTLIST source
%core.attribute.set; >
<!-- language -->
<!-- see languageCodes.mod, an entity set
comprising a formal vocabulary for
language, derived from ISO 639 and 639-2 -->
<!ELEMENT language EMPTY >
<!ATTLIST language
code CDATA #REQUIRED
name CDATA #IMPLIED
src CDATA #IMPLIED
%core.attribute.set; >
<!-- relation -->
<!ELEMENT relation EMPTY >
<!ATTLIST relation
%url.attribute.set; >
<!-- coverage -->
<!ELEMENT coverage (geographic | distribution | kernel |
architecture | os)* >
<!ATTLIST coverage
%core.attribute.set; >
<!-- see countryCodes.mod, an entity set
comprising a formal vocabulary for
geographic, derived from ISO 3166-1 -->
<!-- geographic -->
<!ELEMENT geographic (#PCDATA) >
<!ATTLIST geographic
%core.attribute.set; >
<!-- see linuxDistributions.mod, an entity set
comprising a formal vocabulary for
distribution -->
<!-- distribution -->
<!ELEMENT distribution (#PCDATA) >
<!ATTLIST distribution
%core.attribute.set; >
<!-- kernel -->
<!ELEMENT kernel (#PCDATA) >
<!ATTLIST kernel
%core.attribute.set; >
<!-- architecture -->
<!ELEMENT architecture (#PCDATA) >
<!ATTLIST architecture
%core.attribute.set; >
<!-- os -->
<!ELEMENT os (#PCDATA) >
<!ATTLIST os
%core.attribute.set; >
<!-- rights -->
<!-- see licenseTypes.mod, an entity set
comprising a formal vocabulary for rights -->
<!ELEMENT rights (holder | license)* >
<!ATTLIST rights
%core.attribute.set; >
<!-- holder -->
<!ELEMENT holder EMPTY >
<!ATTLIST holder
name CDATA #REQUIRED
%core.attribute.set; >
<!-- license -->
<!ELEMENT license EMPTY >
<!ATTLIST license
name CDATA #REQUIRED
url CDATA #REQUIRED
version CDATA #IMPLIED
%core.attribute.set; >
<!-- ............................................................. -->
<!-- ............................................................. -->
|
|
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: 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
|
|
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: <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: 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: 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: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 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: 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... = | +----------------------------------------------------------------------+ |
1467 messages has been excluded from this view by a project administrator.