Re: [Scrollkeeper-devel] strange DTD changes

[Dan M. <mu...@al...>]

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