[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] Feature Request: Make tgroup optional w/in table
I concur with Paul: this isn't a table issue, but a conref issue. This basically means that you cannot resolve the issue by dinkering with the table's content model, because this issue arises with ANY element that has mandatory children. You cannot conref to a topic or a task or a task step without adding mandatory child elements. You also cannot resolve this issue by going through every single standard DITA element and relaxing its content model to make all its children optional, because specialization allows you to add additional restrictions (like mandatory children). You'd have to change not only all standard DITA elements, but also all future and possible specializations. I suggest we continue to leave this issue to be handled by editor implementations. Idiom's implementation creates conrefs by inserting mandatory child elements, ensuring validity, and I'm sure others do the same thing. Since DITA users tend to use WYSIWYG editors, I don't see the "extra" elements being an issue. It's just inelegant from the perspective of someone viewing the raw XML source. Chris -----Original Message----- From: Grosso, Paul [mailto:pgrosso@ptc.com] Sent: Saturday, March 03, 2007 6:21 PM To: dita@lists.oasis-open.org Subject: RE: [dita] Feature Request: Make tgroup optional w/in table This isn't really an OASIS table issue. It's a conref issue. The problem arises whenever you conref to an element whose content model doesn't allow it to be empty. The problem is just due to the basic definitions of XML and DITA's conref. Basically, the design of DITA's conref is not completely compatible with XML. We could allow DITA's table element to be empty--and assume this situation would only be used in the conref case--but if the table element is not empty, tgroup needs to be required. paul > -----Original Message----- > From: Don Day [mailto:dond@us.ibm.com] > Sent: Friday, 2007 March 02 22:27 > To: W. Eliot Kimber > Cc: dita@lists.oasis-open.org > Subject: Re: [dita] Feature Request: Make tgroup optional w/in table > > The story seems related to the choice of the OASIS XML Exchange Table > Model as the definitive version for DITA. > http://www.oasis-open.org/specs/tm9901.html > > In that default DTD, the content model for table is effectively: > > <!ENTITY % tbl.table-titles.mdl "%titles;,"> > <!ENTITY % tbl.table-main.mdl "tgroup+"> > <!ENTITY % tbl.table.mdl "%tbl.table-titles.mdl; > %tbl.table-main.mdl;"> > ... > <!ELEMENT %tbl.table.name; (%tbl.table.mdl;)> > > In the DITA adaptation, the equivalent specialization-enabled > declaration > is: > > <!ENTITY % tbl.table-titles.mdl "((%title;)?, (%desc;)?)?,"> > <!ENTITY % tbl.table-main.mdl "(%tgroup;)+"> > <!ENTITY % tbl.table.mdl "%tbl.table-titles.mdl; > %tbl.table-main.mdl;"> > ... > <!ELEMENT %tbl.table.name; (%tbl.table.mdl;)> > > Thus, tgroup effectively remains one or more by inheritance from the > Exchange Table Model. Due to the wide use of this model across most > XML DTDs that use tables, we are sort of faced with either changing > this design uniquely for DITA, or with pushing the Why question back > to the framers of the 1999 document. With my DITA specialization hat > on, I can see the rationale of your request. With my Chair hat on, I > worry what impact such change might have on editor implementations > that may have somehow built dependencies on the requiredness of tgroup > (ensuring that new tables get a default setup when created, perhaps) > in which the relaxation might affect how usability is perceived. > > > "W. Eliot Kimber" > <ekimber@innodata-isogen.com> > To <dita@lists.oasis-open.org> > 03/02/2007 02:48 > > Subject: [dita] Feature Request: Make tgroup > optional w/in table > > I am creating documents from legacy where all the tables are being > used by reference. > > Because tgroup is required w/in table, it means that all my conrefs > look like this: > > <table conref="tables_205-15-60.xml#table-001"> > <tgroup cols="1"> > <tbody> > <row> > <entry></entry> > </row> > </tbody> > </tgroup> > </table> > > Which seems a little silly.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]