OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

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


Subject: RE: [dita] HTML vs CALS tables so far


Hi, Yas:

Would it be easier for HTML and CALS tables to coexist if the HTML namespace (http://www.w3.org/1999/xhtml) and the "html" namespace prefix were used to qualify the HTML table?

That would be a more standard approach than renaming the table and tgroup element. It would complicate the emerging use of namespaces within DITA to identify specialization package types, but incorporating non-DITA vocabularies and their namespaces within DITA specialization packages is probably something we'll need to address at some point in the future anyway.


What do you think?


Erik Hennum
ehennum@us.ibm.com


"Yas Etessam" <yas.etessam@blastradius.com> wrote on 08/09/2004 06:51:40 PM:

> Erik, thanks for the useful summary.

>  
> In terms of the two table models/single vocab. suggestion, an HTML
> element called "htmltable" could still be rendered as a table in
> Author.  Some standard built-in functions such as "Insert Row",
> "Delete Column" currently recognize the HTML/CALS ( including
> Exchange ) tags and haven't been designed to use the "html" prefix.
> Do other CMS/Authoring tools support "htmltable" tags without losing
> any existing functionality?  And would this type of prefixing
> satisfy our HTML advocates?

>  
> Looking forward to tomorrow's meeting,
>  
>  
> YAS ETESSAM Consultant, XMetaL
>  
> yas.etessam@blastradius.com
>  
> BLAST RADIUS XMetaL http://www.xmetal.com
> This e-mail, and any attachments thereto, is intended only for use
> by the addressee(s) named herein and may contain legally privileged
> and/or confidential information. If you are not the intended
> recipient of this e-mail, you are hereby notified that any
> dissemination, distribution or copying of this e-mail, and any
> attachments thereto, is strictly prohibited. If you have received
> this e-mail in error, please notify me by replying to this message
> and permanently delete the original and any copy of this e-mail and
> any printout thereof.

> -----Original Message-----
> From: Erik Hennum [mailto:ehennum@us.ibm.com]
> Sent: Monday, August 09, 2004 4:20 PM
> To: DITA TC list
> Subject: [dita] HTML vs CALS tables so far

> Esteemed TC:
>
> I know we'd all like to reach closure on the table issue, so I'd
> like to try to summarize the discussion thus far in preparation for
> the meeting tomorrow. (Please correct any misrepresentations.)
>
> ** Debbie and others indicate that HTML table is the current and
> future direction for their clients.
>
> ** Paul and others raise the issue that CALS table has the control
> needed for print and is widely used by existing content providers.
>
> ** For DocBook, Paul combined both HTML and CALS table within a
> single model and advises against that approach.
>
>
> I'd also like to raise some questions in hopes that they'll help
> with weighing the alternatives:
>
> ** If your first choice is one of the options, is your second choice
> the other option or both options?
>
> ** Could our statement of direction be that we expect to deprecate
> the CALS option after the HTML option adds equivalent print control?
>
> ** Could we reduce complexity by using distinct elements for each
> table model instead of having a single table model that covers both
> variants? For instance, where elements have the same name in both
> models, we might add an HTML prefix for now (as in htmltable and
> htmltgroup) and use namespace prefixes in the future once we have a
> coherent story for namespaces and specialization.
>
> ** Does the CALS exchange model have enough benefits to justify
> migrating current DITA adopters from the existing CALS model?
> Especially if we deprecate CALS to some extent in favor of HTML.
>
>
> Finally, a key question: will tool vendors (such as editor and
> content management system suppliers) have trouble supporting two
> table models in one vocabulary?
>
>
> Hoping that's useful,
>
>
> Erik Hennum
> ehennum@us.ibm.com



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