Re: omf files that dont validate

[Malcolm Tredinnick <malcolm commsecure com au>]

On Fri, Sep 20, 2002 at 02:16:37PM +0800, James Henstridge wrote:
> Malcolm Tredinnick wrote:
> >Now, I can sympathise with an argument that says the current DTD is a
> >little inflexible in that it requires the fields to be in a particular
> >order. Since the data in an OMF file is really just a bag of items, we
> >should probably allow the tags in any order and that's a backwards
> >compatible change to the DTD that ships with scrollkeeper. File a bug
> >against scrollkeeper (at sourceforge) to get remind me to look at that
> >if you like.
> >
> The DTD probably requires the ordering so that it can impose limits on 
> the number of each element type that can be included.  If you wanted to 
> get rid of the ordering constraint, you need to use something like 
> (a|b|c|d)* instead of (a,b,c,d), which doesn't protect you against 
> unwanted repeating elements (eg. it might let an OMF file through with 
> multiple series ids or something).  To get the desired validation 
> behaviour, you would need schemas or relax-ng.

Yes, I suspect that's the reason. Another case of needing the '&'
operator from SGML in order to get both benefits (no ordering and
quantifying). However, I would rather widen the set of "allowable, but
stupid" OMF files to ease the pain of writing them. In
scrollkeeper-land, it has already been mooted to have handling inside
scrollkeeper to just quietly ignore multiple legalnotices, for example
(or log a warning, but accept the DTD).

I don't know what the general thinking is on things like this. I prefer
to have DTDs as specifying a superset of what I really want, but
being easy to use. But DV or Ankh (or others) may be jumping up and down
when they read this and point out that it should be like it is now.

*shrug* Making things pleasant all around just makes my brain hurt. :-(

Malcolm