Re: svn commit: r828678 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/afp: goca/ modca/ modca/triplets/

[Chris Bowditch]

Adrian Cumiskey wrote:
Hi Chris,

Hi Adrian,

thanks for your input on this. It is appreciated.



2009/11/26 Chris Bowditch <bowditch_ch...@hotmail.com 
<mailto:bowditch_ch...@hotmail.com>>

    Adrian Cumiskey wrote:

        I agree it might be better if the AttributeQualifier triplet is
        at the end of the list as it is optional, and FullyQualifiedName
        and AttributeValue are both manditory.  I would be very
        surprised if this should cause a problem as I don't believe
        there are any ordering rules for triplets.  I'd be interested to
        hear how bug manifests itself?


    MO:DCA Specification dictates the order of the triplets, here:
    
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/HA3M5M00/5.82.2?SHELF=APSBK320&DT=20010307105730
    
<http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/HA3M5M00/5.82.2?SHELF=APSBK320&DT=20010307105730>


I don't believe that it does, this is just a list of possible applicable 
triplets for the TagLogicalElement structure field, the order in which 
they are present should not be important.

You could well be right here. Since I am not an expert on AFP I asked 
Jeremias for his thoughts too. We could see nothing in the MO:DCA spec 
to confirm or deny either way.

 

    Attribute Qualifier is the last part of TLE structured field.

    One of our customers has a process that extracts the TLE values
    which now fails because the 10 bytes of the AttributeQualifier occur
    in front of the value.


I do not think that it is correct for your customer to make this 
assumption about the position of the triplet in the structured field 
data.   AFAIK it is still perfectly valid AFP so long as all the 
mandatory triplets are present and all the structured field data lengths 
and triplet data lengths are present and correct.  But if this patch 
fixes the problem for your client I have no problem with you applying it.

Based on what you've told me today I tend to agree that anyone writing 
an AFP Parser should not assume the order of triplets matches the 
specification. However, I would imagine that a lot of people writing 
such a parser would tend to (incorrectly?) assume that the order of the 
triplets would match that shown in the structured field definition in 
the specification. So if FOP does choose to deviate from the shown 
order, we may find that AFP streams cannot be processed by some 
printers/viewers/software. Which is not desirable.

 
Adrian.

Thanks,

Chris