MHonArc v2.5.0b2 -->
dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [dita] attribute extensibility - summary
The specialization proposal (issue 20,
use-case 1 - but with the modified format proposed by Robert) adds a couple
of extra pieces:- using props instead of otherprops
(to avoid the question of "what is 'other' in relation to?")- allowing relationships between the
conditional processing attributes, as well as between those attributes
and props (ie allow multiple levels instead of just two) - so you can manage
opsys conditions as part of platform if you want to, as well as considering
it a part of props or a solo attribute.We had discussed whether to make the
generalized syntax directly authorable (it was a draft-comment question
in the posted proposal) - on the TC call at the time, consensus seemed
to be against that idea - but I don't have a strong opinion one way or
the other, and I do see the potential value of being able to say "I
don't have time to specialize and modify the doctype, so let me author
semantic groupings in my current attributes and get the same effect".
If we choose to document the format as directly authorable, then the main
difference between your proposal and the specialization proposal would
be whether you can have those semantic groupings in just props/otherprops,
or in any conditional processing attribute.Michael Priestley
IBM DITA Architect and Classification Schema PDT Lead
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25
At this juncture, I have what I hope is a simple question.
I understand that users want to be able to conditionalize
on new attributes and new values, and I understand that
it would be optimal to be able to author those attributes
and values directly into the content.
But for a moment, lets assume there is a transformation
from this optimal markup into one that merely uses our
existing support for otherprops to "encode" the conditional
attribute information using DITA 1.0.1 markup. We can even
assume a reverse transformation on the other side so that
end users can work in the "augmented conditional attribute"
markup, but the actual preserved markup just uses otherprops.
Is there any underlying conditional processing functionality
that could not be made available to DITA users in this scenario?
paul
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]