Isn't the mechanism a little risky since there is
no validation on possible values from the DTD (typos happen all the time)?
Moreover, there is no way to control where and when these are allowed to be used
or to force people to use them. Shouldn't we be afraid of
inconsistencies?
Specialization takes less then a day. Cleaning up after a
false specialization may take much longer and you need to create XSL and/or
CSS for both if you actually want to use them. I'm not sure I get the use
case.
France (the skeptic) Baril
From: Erik Hennum [mailto:]
Sent: June 13, 2006 1:20 PM
To: France Baril
Cc:
; Grosso, Paul
Subject: RE: [dita]
outputclass on map elements
Hi, France:
Your concern makes sense -- it creates a problem if
writers use the outputclass attribute for presentation, as in:
<p
outputclass="Palatino12pt">...</p>
It is also possible, however,
to use the outputclass attribute for informal semantic extension, as
in:
<p outputclass="background">...</p>
Making such
informal extension available to adopters seems pragmatic (though, in retrospect,
the attribute name would be better if it prompted this approach).
In
passing, that's a good way to mock up and evaluate a potential specialization -
by creating an instance in the base type with outputclass attributes indicating
the proposed specialized elements.
Hoping that's
useful,
Erik Hennum
'
src="gif00048.gif" width=16 border=0>"France Baril"
<>
"France Baril"
<>
06/13/2006 08:53 AM
To
<>
cc
Erik Hennum/Oakland/IBM@IBMUS, "Grosso, Paul"
<>
Subject
RE: [dita] outputclass on map
elements
I'm with Paul on this, it makes me very nervous too,
but not because it's HTML only.
My reason is that having CSS information in the content
means that you can never redesign the HTML style completely or use CSS that
don't have that class defined. I wonder if the proposal should not be to remove
this attribute from topics instead of adding it to maps.
I'm aware this could cause
issues with backward compatibity, but it could prevent other issues for users
down the road.
Moreover, shouldn't most writers be completely ignorant of the CSS
definitions?
France Baril
Documentation Architect/Architecte documentaire
IXIASOFT
tel.: + 1 514 279-4942 (new extension number
350)
+ 1 877 279-IXIA (new
extension number 350)
fax: + 1
514 279-3947
[ www.ixiasoft.com ]
Let's Talk XML
From: Erik Hennum [mailto:]
Sent: June 7, 2006 1:57
PM
To: Grosso,
Paul
Cc:
Subject: RE: [dita] outputclass on
map elements
Hi, Paul:
To clarify, the outputclass attribute is
available on the topic elements in DITA 1.0. The attribute should have been
provided on the DITA map elements as well -- hence the bug fix.
The
outputclass attribute really fills a role similar to the DocBook role attribute.
Where the output format has a concept of class or role (as with HTML), the
outputclass can be copied into the output, but its primary purpose is to provide
informal semantic extension rather than stuff names into the HTML class
attribute.
The attribute could have a better name.
Erik
Hennum
"Grosso, Paul"
<>
"Grosso, Paul" <>
06/07/2006 07:24 AM
To
<>
cc
Subject
RE: [dita] outputclass on map
elements
It makes me nervous to embed HTML-only stuff in the
DITA model.
How do you propose to treat this attribute for print/pdf output? How
do you propose to write up this attribute in the spec in an output-independent
fashion that still remains useful?
paul
From: Erik
Hennum [mailto:]
Sent: Tuesday, 2006 June 06 17:01
To:
Subject: [dita] outputclass on
map elements
Hi, Esteemed Technical Committee:
The 1.1 bug list
(http://wiki.oasis-open.org/dita/Bug_fixes_for_DITA_1%2e1#preview) has an item that never received final disposition -- adding the
outputclass attribute to the map elements (<map>, <topicref>,
<navref>, <anchor>, and <reltable>):
http://lists.oasis-open.org/archives/dita/200602/msg00082.html
To recap, the outputclass attribute assigns an informal role to
an element. As such, outputclass is quite useful for extending the semantic
without formal specialization. For instance, you can use outputclass to mock up
a specialization in the base document type or to create handles for custom
processing. Typical output processing for HTML copies the outputclass into the
class attribute so users can create custom CSS styling.
Currently,
outputclass is only available on topic elements and not on map elements. As a
result, you can't easily mock up a map specialization or provide handles for
custom map processing.
The main implication of map outputclass for the
base output processing would seem to be to collect the outputclass values for
the topicref and provide them on the outermost wrapper of the HTML content for
the topic. The latter enhancement would let users style a topic in CSS based on
the role played by a topic within a map.
The outputclass attribute is
close to being a universal attribute -- it applies to a similarly large list of
elements and merits similar treatment. I'd like to request that we finalize this
bug fix at the next meeting.
Thanks,
Erik
Hennum
