[Top] [All Lists]

Re: Text/enriched ambiguity

1993-10-30 16:23:26
              is how do you *know* that colorentries won't 
someday include some other compensating parameter?   And even if 
we assume  (safely, I'm sure you'll agree)  that primary colors 
will always be composed of R, G & B,  we have to use a different 
mechanism to parse a colorentry than to parse something else. 
Well no ... you could have some table that says  "colorentries 
have exactly three parameters",  but that doesn't work for things 
that have variable numbers of parameters.   Ugh! 

This discussion started, I believe, with a question as how to best handle
the insides of a <param> block.  Such blocks are explicitly intended to
contain application-specific information in a format that is not yet defined.
I'd expect that the <colorentry> example would be "wrapped up" in a
<param> block.  So, trying to define a rigid format for such blocks would
be premature, until such time as someone feels the need for <param>.

However, if a consistent mechanism for <param> blocks is required, it
shouldn't be difficult to come up with one.  e.g.

        block = 1*(tag [ params ])
        tag = identifier / number / string
        params = "{" block "}"

So, the color example would be:

        <colorentry>red{255 0 0} blue{0 0 255}</colorentry>

This structure can be extended with arbitrary levels of nesting as
necessary, and is pretty close to the way most tagged file formats
are designed to accomodate arbitrary future extensions.

But, I'm not sure I'd like to see this adopted until there is a real need
for it, which at the moment I can't see.



<Prev in Thread] Current Thread [Next in Thread>