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] 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



"Grosso, Paul" <pgrosso@ptc.com>

04/27/2006 10:54 AM

To
<dita@lists.oasis-open.org>
cc
Subject
RE: [dita] attribute extensibility - summary





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]