OASIS DocBook TC2

Re: [docbook-tc] adding CALS attrs to HTML tables

  • 1.  Re: [docbook-tc] adding CALS attrs to HTML tables

    Posted 04-08-2005 18:31
     MHonArc v2.5.0b2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    docbook-tc message

    [Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


    Subject: Re: [docbook-tc] adding CALS attrs to HTML tables


    Hi Paul,
    As you say, examining the purity of CALS tables in DocBook is useful.  The
    CALS table model supports two parameter entities %bodyatts; and %secur; for
    attributes, which don't seem to be defined in the CALS standard. [1]  I take
    this to mean that any number of additional attributes can be defined in
    those PEs to add to CALS tables.  In DocBook, the bodyatts PE is populated
    with floatstyle, label, and the new rowheader. The secur PE is populated
    with all the DocBook common attributes, of which there are 17 in  V5.0.  So
    CALS interoperability seems to permit the addition of any number of
    attributes on the table element through these two extension parameters.
    
    The HTML table model does not have such an extension mechanism.  In the
    current proposal for HTML tables in V5.0 [2], the common attributes are not
    permitted on the HTML table element or its HTML descendents.  I have to
    wonder if that was intentional, or if this concept of table model purity
    requires it.  I suspect DocBook users would revolt if they didn't have the
    common attribs on HTML tables.  So perhaps we should also discuss whether
    HTML table elements should permit the DocBook common attribs.  If those are
    permitted, then adding a couple more attribs from the CALS table model seems
    OK.
    
    Regarding interoperability of table models, currently an XML application
    supporting a CALS table has to support, or at least recognize, the
    additional attributes defined in the bodyatts and secur parameter entities.
    For example, an editing application needs to read the schema and add those
    attributes to the choice list for CALS tables.  Those attributes don't
    affect the element content models, so the application can properly arrange
    the rows and columns on the screen.
    
    If an application also supports HTML table markup in DocBook, they will also
    have to read the schema, because the table cells contain content that is not
    necessarily HTML.  If it handles the CALS tables with arbitrary attributes,
    it would seem adding attributes to HTML tables would not create problems.
    Again, the extra attributes would not modify the content models of the HTML
    table elements.
    
    If interoperability means moving an HTML table between a DocBook document
    and an HTML file, then a few extra attributes in the HTML table would not be
    a problem.  HTML browsers simply ignore extra attributes.  A bigger problem
    would be any DocBook markup in the table cells, which could create
    unreadable output.  In a sense, we have already created a hybrid table model
    by permitting DocBook markup within an HTML table cell.  So I think it would
    be useful for those who desire interoperability to define it in terms of
    real requirements.
    
    So let's first decide if HTML tables should have the common attribs.
    
    [1] http://www.oasis-open.org/specs/a502.htm
    [2] http://www.docbook.org/tdg5/en/html/html.table.html
    
    Bob Stayton
    Sagehill Enterprises
    DocBook Consulting
    bobs@sagehill.net