Menu
▾
▴
scrollkeeper-devel
|
From: Martijn v. B. <ma...@ee...> - 2002-05-17 16:20:21
|
Hi,
I was updating my db2omf.xsl stylesheet, (the old version is at
gnome-docu/gdp/tools/db2omf.xsl if anyone wants to add it to
the 'other resources' section of the omf file manual) when I
noticed that the current DTD doesn't really deserve the
term 'scrollkeeper OMF variant', since it isn't a variant, but
a completely different beast.
The initial check-in changelog entry says:
* extract/dtds/scrollkeeper-omf.dtd: Adding this file from
Eric Baudais <ba...@ok...>. It is the OMF DTD
with a few ScrollKeeper-specific variations.
Eventually we will feed these upstream.
But these are hardly 'a few variations'
instead of:
<creator>
<person>
<firstName>Martijn</firstName>
<lastName>van Beers</lastName>
<email>lo...@us...</email>
</person>
</creator>
according to the docs, one now has to do:
<creator>
lo...@us... (Martijn van Beers)
</creator>
which begs the question why use xml at all anymore when you really seem
to be wanting to parse all the relevant information out of a simple
string anyway.
I've looked through the scrollkeeper-devel and gnome-doc-list archives,
but I haven't been able to find any discussion that might explain these
very odd changes. Please enlighten me,
Martijn
|
|
From: Dan M. <mu...@al...> - 2002-05-20 05:01:35
|
Hi Martijn,
I had a similar reluctance to doing away with the beauty and convention o=
f
XML and <person>. The reason why we are currently recommending the form
"lo...@us... (Martijn van Beers)" is because that is what
is specified by the OMF spec for <creator>. To quote the spec:
---
1. Author or Creator
Label: CREATOR
Obligation: Mandatory
Maximum Occurrence : Repeatable
The person or organization primarily responsible for creating the
intellectual content of the resource. CREATOR should appear in RFC822
format (http://info.internet.isi.edu:80/in-notes/rfc/files/rfc822.txt).
Preferred format: mai...@si... (Full Name)
---
I'm open to arguments for why we should or should not use the <person>=20
tag in place of RFC822. If we get a concencus, this would be the best=20
time to make updates, but in such a way that it doesn't break OMF files=20
that were written lately.
Dan
On Thu, 17 May 2001, Martijn van Beers wrote:
> Hi,
>=20
> I was updating my db2omf.xsl stylesheet, (the old version is at
> gnome-docu/gdp/tools/db2omf.xsl if anyone wants to add it to
> the 'other resources' section of the omf file manual) when I
> noticed that the current DTD doesn't really deserve the
> term 'scrollkeeper OMF variant', since it isn't a variant, but
> a completely different beast.
>=20
> The initial check-in changelog entry says:
>=20
> * extract/dtds/scrollkeeper-omf.dtd: Adding this file from=20
> Eric Baudais <ba...@ok...>. It is the OMF DTD
> with a few ScrollKeeper-specific variations.
> Eventually we will feed these upstream.
>=20
> But these are hardly 'a few variations'
>=20
> instead of:
>=20
> <creator>
> <person>
> <firstName>Martijn</firstName>
> <lastName>van Beers</lastName>
> <email>lo...@us...</email>
> </person>
> </creator>
>=20
> according to the docs, one now has to do:
> <creator>
> lo...@us... (Martijn van Beers)
> </creator>
>=20
> which begs the question why use xml at all anymore when you really seem
> to be wanting to parse all the relevant information out of a simple
> string anyway.
>=20
> I've looked through the scrollkeeper-devel and gnome-doc-list archives,
> but I haven't been able to find any discussion that might explain these
> very odd changes. Please enlighten me,
>=20
>=20
> Martijn
>=20
>=20
> _______________________________________________________________
>=20
> Hundreds of nodes, one monster rendering program.
> Now that=92s a super model! Visit http://clustering.foundries.sf.net/
> _______________________________________________
> Scrollkeeper-devel mailing list
> Scr...@li...
> https://lists.sourceforge.net/lists/listinfo/scrollkeeper-devel
>=20
|
|
From: Martijn v. B. <ma...@ee...> - 2002-05-20 10:12:03
|
On Mon, May 20, 2002 at 12:01:20AM -0500, Dan Mueth wrote: > > Hi Martijn, > > I had a similar reluctance to doing away with the beauty and convention of > XML and <person>. The reason why we are currently recommending the form > "lo...@us... (Martijn van Beers)" is because that is what > is specified by the OMF spec for <creator>. To quote the spec: Hrm, very strange. According to their DTD (http://www.ibiblio.org/pub/Linux/metadata/OMF.dtd) you do use <person>. Also, their OMF generation CGI also uses the <person> ... After reading some of the omf list archives (and I thought other web interfaces to mailing lists were horrid!) ... It seems like you guys have assumed the 'spec' to be authorative, while they seem to be saying ask. > I'm open to arguments for why we should or should not use the <person> > tag in place of RFC822. * XML is a markup language. you mark up things humans understand already, so an application can easily make sense of them too. rfc822 format is not an example of this * the original matches much better with DocBook's author/etc tags While we're discussing changes, why was category changed into an attribute <subject category="foo" /> instead of <subject>foo</subject> I really don't see any advantages of this. (and why does gnome need it's own category anyway?) I do like the new syntax for <format>, but it may be a good idea to add an optional attribute to specify an url where to fetch the DTD Another thing I don't like in the changed DTD is how rights turned into one element with just attributes <rights> <license name="FDL" version="1.1" url="foo" /> <holder>joe shmoe</holder> </rights> makes much more sense than the way it is now. Another regression from the original DTD is the <version> tag. putting things like a description into an attribute really doesn't make much sense. (http://lists.xml.org/archives/xml-dev/200205/msg01027.html for a good thread on element vs. attribute) Martijn |
|
From: Gregory L. <gle...@li...> - 2002-05-21 07:01:24
|
On Mon, 2002-05-20 at 03:08, Martijn van Beers wrote: > On Mon, May 20, 2002 at 12:01:20AM -0500, Dan Mueth wrote: > > > > Hi Martijn, > > > > I had a similar reluctance to doing away with the beauty and convention of > > XML and <person>. The reason why we are currently recommending the form > > "lo...@us... (Martijn van Beers)" is because that is what > > is specified by the OMF spec for <creator>. To quote the spec: > > Hrm, very strange. According to their DTD > (http://www.ibiblio.org/pub/Linux/metadata/OMF.dtd) you do > use <person>. Also, their OMF generation CGI also uses the <person> Yeah, but the DTD doesn't necessarily reflect the spec, nor does the CGI. I tried to get this straightened up, but I didn't have much luck. I've since stopped trying, I don't have the time to work on it to the extent that's required. Greg -- Portland, Oregon, USA. Please don't copy me on replies to the list. |
|
From: Martijn v. B. <ma...@ee...> - 2002-05-21 07:53:33
|
On Mon, May 20, 2002 at 11:59:38PM -0700, Gregory Leblanc wrote: > > Yeah, but the DTD doesn't necessarily reflect the spec, nor does the > CGI. I tried to get this straightened up, but I didn't have much luck. > I've since stopped trying, I don't have the time to work on it to the > extent that's required. But why pick the worst of the three as your reference?? Martijn |
|
From: Dan M. <mu...@al...> - 2002-05-21 17:38:15
|
On Tue, 21 May 2002, Martijn van Beers wrote: > On Mon, May 20, 2002 at 11:59:38PM -0700, Gregory Leblanc wrote: > > > > Yeah, but the DTD doesn't necessarily reflect the spec, nor does the > > CGI. I tried to get this straightened up, but I didn't have much luck. > > I've since stopped trying, I don't have the time to work on it to the > > extent that's required. > > But why pick the worst of the three as your reference?? Well, the spec should be the reference, not any particular implementation of the spec. Having said that, one may argue that as long as one can create an OMF DTD and an accompanying XSLT stylesheet that outputs the email addresses in RFC822 format, then it doesn't really matter what the internal structure of the email address is in the XML file. I think the spec is for the information, and not the way it is stored, so I think you can create an arbitrary binary data format so long as you have a way to decode it into the form which follows the OMF spec. In the case of <person>, the conversion from <person> to RFC822 is simple. The reverse is not always possible, which is unfortunate. It would be nice if you could convert an OMF database from one format to another without problems or loss. By enriching the <creator>, we may lose this flexibility. It sounds like we may want to support both RFC822 (in the tag body) and <person> (as a child) for <creator>. This would allow an XML OMF file to be converted to format B and then back, and still have valid OMF data (although the richness of <person> would be lost in the process). What do you think about this approach? Dan |
|
From: Martijn v. B. <ma...@ee...> - 2002-05-21 18:47:00
|
On Tue, May 21, 2002 at 12:38:01PM -0500, Dan Mueth wrote: > Well, the spec should be the reference, not any particular implementation > of the spec. From what I've seen on the mailing-list neither the spec nor any implementation was set in stone. > In the case of <person>, the conversion from <person> to RFC822 is simple. > The reverse is not always possible, which is unfortunate. It would be > nice if you could convert an OMF database from one format to another > without problems or loss. But *why* would you want to do that? If you think of the spec as the final word on the syntax, then you cannot have <person> & friends. And if you have <person>, you really have no use for a dumbed down representation of the data. (maybe we should try to get the original OMF people involved into this) Martijn |
|
From: David M. <da...@lu...> - 2002-05-21 19:59:41
|
On Mon, May 20, 2002 at 12:08:21PM +0200, Martijn van Beers wrote: > On Mon, May 20, 2002 at 12:01:20AM -0500, Dan Mueth wrote: > > > > Hi Martijn, > > > > I had a similar reluctance to doing away with the beauty and convention of > > XML and <person>. The reason why we are currently recommending the form > > "lo...@us... (Martijn van Beers)" is because that is what > > is specified by the OMF spec for <creator>. To quote the spec: > > Hrm, very strange. According to their DTD > (http://www.ibiblio.org/pub/Linux/metadata/OMF.dtd) you do > use <person>. Also, their OMF generation CGI also uses the <person> > > ... After reading some of the omf list archives (and I thought other > web interfaces to mailing lists were horrid!) ... > > It seems like you guys have assumed the 'spec' to be authorative, > while they seem to be saying ask. > > > I'm open to arguments for why we should or should not use the <person> > > tag in place of RFC822. > > * XML is a markup language. you mark up things humans understand > already, so an application can easily make sense of them too. > rfc822 format is not an example of this I very much agree with this. I think going rfc822 was a mistake, and would like to see it back the way it was. Keep the XML, well, XML. -- David C. Merrill http://www.lupercalia.net Linux Documentation Project da...@lu... Lead Developer http://www.tldp.org The heart may freeze or it can burn The pain will ease if I can learn There is no future There is no past I live this moment as my last There's only us There's only this Forget regret Or life is yours to miss No other road No other way No day but today -- RENT |
|
From: Martijn v. B. <ma...@ee...> - 2002-05-25 19:41:49
|
On Mon, May 20, 2002 at 12:01:20AM -0500, Dan Mueth wrote:
> I'm open to arguments for why we should or should not use the <person>
> tag in place of RFC822.
So, I happened on Eric Baudais on irc the other day, and we had the
following enlightening discussion:
[...]
* LotR thwaps drake for writing such a lousy one
<drake> I was just doing as I was told to anyways. I think SK should
use V2 of OMF anyways.
<drake> I wrote the DTD for that one with an emphasis on
compliance with V1.0 of the OMF.
<LotR> there's a newer version of the OMF spec then?
<drake> Yes, it does things The Right Way (tm). It's either 1.2
of 2.0...cannot remember which now. SK uses the older OMF spec.
<LotR> url?
<LotR> (the website only seems to have 1.0)
<drake> Look at the DTD at
http://ibiblio.org/pub/Linux/metadata/OMF.dtd
<LotR> oh, that's newer?
<drake> Also take a look at
http://dulug.duke.edu/~mark/docs/dtds/xml/omf-1.1/index.html
<LotR> now I'm really confused
<LotR> was there also a 1.0 DTD?
<drake> Yes, that is the one I modified and SK uses.
<LotR> but earlier OMF files already used the <person> bits from
more recent DTDs
<drake> What SK was using prior was a format halfway between OMF
1.0 and OMF 1.1. I do not think that OMF 1.0 defined <person>.
<LotR> oh
<LotR> so why was the decision made to use V1.0?
<LotR> and if you think we should use a newer version, could you
weigh in on the current thread I started?
<drake> I don't think there was a decision, but SK had always been
using V1.0.
<drake> Okay, I think that Dan told me that V1.0 of OMF never had
a DTD, but V1.1 of OMF did.
<drake> I looked at the V1.1 DTD and saw there were serious
changes between the published documentation from OMF and the DTD.
<drake> Example: There is a toplevel element <versionGroup> which
has a child of <version>. <version> has children <id>, <date>,
and <description>.
<LotR> yeah, the newer ones are much better xml
<drake> This contradicts what the OMF element description says,
which is that there is one element <version> with three
attributes, version.identifier, version.date, and
version.description.
<drake> Since Dan had been using and relying on the V1.0
documentation, I just reconstructed what the DTD would be like
if one was written for V1.0. Then I modified it for SK's
specific uses.
<LotR> the OMF people are obviously not very good at version
management :)
<drake> Yes, it's rather a mess.
<drake> That is the basic history and a lot of my thoughts on how
I wrote the DTD which is now in SK.
<drake> Now that we have something defined, I think people can
make cases on whether the DTD is good for SK or if it should be
modified and updated.
[...]
So, it seems the spec was for version 1.0 of the DTD (which doesn't seem
to have ever existed), and old scrollkeeper versions seem to have used
some version of the 1.1 version of the DTD. Hopefully we can change back
to basing the scrollkeeper DTD on the latest OMF DTD, which is much more
sane ASAP after the gnome 2.0 release. I'll try to create a DTD based on
it, with the extra information scrollkeeper wants, like the <relation> tag,
and send it to the list for discussion.
Martijn
|
|
From: Dan M. <mu...@al...> - 2002-05-27 06:05:45
|
Thanks for the discussion. It is nice to read it and preserve it here. Thanks also for volunteering to work on the DTD. I'm sure you and Eric can come up with a great new version. I think in general the OMF has been languishing a bit, and the discrepencies between the spec and DTD are annoying. It would be good to close up the gaps. Could anybody comment on the viability of writing a stylesheet to convert OMF files from one DTD version to another? It seems completely doable, and I think John has already done this for migrating OMF files from SK-0.2 to SK-0.3.x/0.4, although I'm not sure what the final verdict is on how well it works. Comments John? I think we generally want to get any nasty bugs remaining in 0.3.x fixed and put out 0.4.0 soon. Then we can start working on some of these problems in the 0.5.x developer series. So far I think the big changes for 0.5.x/0.6.0 are: 1) DTD cleanup (and stylesheet/code for backward compatibility of OMFs) 2) URI resolution (eg. for cross-referencing documents) Anything else? Technically these should be straightforward, but they both require a fair amount of thought so we come up with a sane standard. Dan On Sat, 25 May 2002, Martijn van Beers wrote: > On Mon, May 20, 2002 at 12:01:20AM -0500, Dan Mueth wrote: > > I'm open to arguments for why we should or should not use the <person> > > tag in place of RFC822. > > > So, I happened on Eric Baudais on irc the other day, and we had the > following enlightening discussion: > > [...] > * LotR thwaps drake for writing such a lousy one > <drake> I was just doing as I was told to anyways. I think SK should > use V2 of OMF anyways. > <drake> I wrote the DTD for that one with an emphasis on > compliance with V1.0 of the OMF. > <LotR> there's a newer version of the OMF spec then? > <drake> Yes, it does things The Right Way (tm). It's either 1.2 > of 2.0...cannot remember which now. SK uses the older OMF spec. > <LotR> url? > <LotR> (the website only seems to have 1.0) > <drake> Look at the DTD at > http://ibiblio.org/pub/Linux/metadata/OMF.dtd > <LotR> oh, that's newer? > <drake> Also take a look at > http://dulug.duke.edu/~mark/docs/dtds/xml/omf-1.1/index.html > <LotR> now I'm really confused > <LotR> was there also a 1.0 DTD? > <drake> Yes, that is the one I modified and SK uses. > <LotR> but earlier OMF files already used the <person> bits from > more recent DTDs > <drake> What SK was using prior was a format halfway between OMF > 1.0 and OMF 1.1. I do not think that OMF 1.0 defined <person>. > <LotR> oh > <LotR> so why was the decision made to use V1.0? > <LotR> and if you think we should use a newer version, could you > weigh in on the current thread I started? > <drake> I don't think there was a decision, but SK had always been > using V1.0. > <drake> Okay, I think that Dan told me that V1.0 of OMF never had > a DTD, but V1.1 of OMF did. > <drake> I looked at the V1.1 DTD and saw there were serious > changes between the published documentation from OMF and the DTD. > <drake> Example: There is a toplevel element <versionGroup> which > has a child of <version>. <version> has children <id>, <date>, > and <description>. > <LotR> yeah, the newer ones are much better xml > <drake> This contradicts what the OMF element description says, > which is that there is one element <version> with three > attributes, version.identifier, version.date, and > version.description. > <drake> Since Dan had been using and relying on the V1.0 > documentation, I just reconstructed what the DTD would be like > if one was written for V1.0. Then I modified it for SK's > specific uses. > <LotR> the OMF people are obviously not very good at version > management :) > <drake> Yes, it's rather a mess. > <drake> That is the basic history and a lot of my thoughts on how > I wrote the DTD which is now in SK. > <drake> Now that we have something defined, I think people can > make cases on whether the DTD is good for SK or if it should be > modified and updated. > [...] > > So, it seems the spec was for version 1.0 of the DTD (which doesn't seem > to have ever existed), and old scrollkeeper versions seem to have used > some version of the 1.1 version of the DTD. Hopefully we can change back > to basing the scrollkeeper DTD on the latest OMF DTD, which is much more > sane ASAP after the gnome 2.0 release. I'll try to create a DTD based on > it, with the extra information scrollkeeper wants, like the <relation> tag, > and send it to the list for discussion. > > > Martijn > > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > Scrollkeeper-devel mailing list > Scr...@li... > https://lists.sourceforge.net/lists/listinfo/scrollkeeper-devel > |
|
From: John F. <jf...@in...> - 2002-05-27 22:25:46
|
On Mon, 2002-05-27 at 00:05, Dan Mueth wrote: > > Could anybody comment on the viability of writing a stylesheet to convert > OMF files from one DTD version to another? It seems completely doable, > and I think John has already done this for migrating OMF files from SK-0.2 > to SK-0.3.x/0.4, although I'm not sure what the final verdict is on how > well it works. Comments John? > It's relatively straightforward if all of the information is captured in the source DTD. My stylesheet worked fine, but since there was no DTD before, some of the source files lacked information required by the DTD, so manual intervention was required. Cheers, John -- John Fleck jf...@in... (h) jf...@ab... (w) http://www.inkstain.net http://www.abqjournal.com "You don't want to die with the music still in you." - John Gardner |