Re: XHTML Modularization and Tables...

I decided to chime in here Mark, sorry.  I am one of the original 
designers of M12N's architecture.  The other is no longer involved with 
the work, but I will do my best.

First, CONGRATULATIONS!  THIS IS GREAT!  This is *exactly* what XHTML 
M12N was designed for.  I am sorry that you are having problems.

Basically, the problem is that XML in a Nutshell gave you a little but 
of bad advice.  You should not be using the flat version of the DTD.  
Because you are, you are getting everything declared ahead of time, and 
it becomes inflexible as you have learned.  Instead, you should be using 
the various modules and a separate driver file for your new hybrid 
markup language.  In this way, you can exactly control the content 
models of everything, including the table element (the parameter entity 
for that is table.content, btw).  For examples of this style of usage, 
have a look at 
http://www.w3.org/TR/xhtml-modularization/dtd_developing.html#s_developingdtds 
- in particular I would look at section E.4.4 - this is largely on point.

I would be happy to help you work your way through this if you run into 
trouble.  Just contact me privately.

Boysko, Glenn wrote:

> Mark:
>
> Here is how we are using the existing XHTML modularization in the 1.1 
> spec.  We have a concept of "layout files" that are used in our 
> product to represent the presentation of some content.  Each layout 
> file is a special hybrid of XHTML and XML.  The XHTML represents the 
> static portions of the presentation. Interspersed in that are dynamic 
> instructions (in the form of XML tags defined by us). 
>  
> The root tag of a layout file is 'layout' (we use a namespace of 
> 'mstrlayout' for all of these new tags).  It can contain just about 
> anything: #PCDATA, and using the XHTML "hook", %Flow.mix%;.  We have 
> already added our own non-root tags to Misc.extra.  Our overall 
> approach is to define our own DTD and include the XHTML 1.1 Flat DTD 
> (xhtml11-flat.dtd), as per the "XML in a Nutshell" book, by Harold and 
> Means (Chapter 7).
>  
> One of the simplest tags is called 'render'.  It is basically a way to 
> call into another Java class (with the resulting content replacing the 
> 'render' tag).
>  
> There is a tag to add attributes with dynamically generated values to 
> the enclosing element (similar in concept to the xsl:attribute element).
>  
> There is a conditional structure (to include one block of XHTML over 
> another based on a dynamic condition).
>  
> Finally, there is a list construct (to introduce iteration into a 
> template of XHTML content).  Lists typically include calls to embedded 
> render elements.
>  
> Overall, the modularization works well.  The problem we have had 
> involve integrating these dynamic tags into a TABLE structure.  For 
> example, there is no "hook" to introduce custom tags into a TABLE 
> structure.  The result is that we've had to undefine all of the TABLE 
> tags (TABLE/TBODY/THEAD/TFOOT/TR/TH/TD/COL/COLGROUP) and redefine 
> their contents to include our tags.
>  
> The most common example would be to define a table with a repeating 
> number of rows.  Each row has elements which are dynamically generated. 
>  
> We also have to redefine META, SELECT, HTML and TITLE to introduce our 
> own tags (as Misc.extra is not used here).
>
> Finally, we've had to change the ID attribute from ID to NMTOKEN as 
> our conditional blocks can have to identical IDs (since only one of 
> the two blocks is ever added to the output stream).
>  
> I guess my main questions are:
>
>    *
>       Is this approach consistent with the designer's intent for
>       modularization of XHTML?
>    *
>       Would it be better to use XML Schemas for this integration of
>       our custom tags with XHTML?  (I'm not very well versed in schemas).
>    *
>       Do you anticipate any problems with this approach and the XHTML
>       2.0 modularization effort?
>
> Thanks,
> Glenn


-- 
Shane P. McCarron                          Phone: +1 763 786-8160 x120
Managing Director                            Fax: +1 763 786-8180
ApTest Minnesota                            Inet: shane@aptest.com

Received on Tuesday, 7 June 2005 15:39:12 UTC