DITA TC Meeting (Conference Call)
has been modified by Don Day
Date: Tuesday, 18 April 2006
Time: 08:00am - 09:00am PT
Event
Description:
DITA
Technical Committtee teleconference
USA
Toll Free Number: 866-566-4838
USA
Toll Number: +1-210-280-1707
PASSCODE:
185771
Agenda:
8:00-8:05
Roll call
8:05-8:10
Review/approve minutes from previous meeting:
* http://lists.oasis-open.org/archives/dita/200604/msg00069.html
(11 April 2006)
Request
a minute taker (regrets from Gershon)
Regular
Business:
* Review #20 metadata proposal (Michael
Priestley)
*
http://www.oasis-open.org/committees/download.php/17329/IssueNumber20.html
Resources
for this meeting:
* DITA Wiki home page:
* http://wiki.oasis-open.org/dita/
Don Day moves to accept the minutes from last week.
Paul Prescod seconds. Accepted.
On to the conditional processing / extensible metadata proposal.
New conditional processing, specialized from
- props (filtering …)
- rev (for revision markup, not to support filtering).
New generic attributes, from a new attribute “base”.
- Need to store attribute values that your processes care about, but don’t need base processing
Allow formal expression of negative values (informal already supported).
Scoped values allowed.
Example: product/edition (can filter on product separately from edition)
Extended syntax for ditaval.
More options for how to flag, and how to filter, content based on dita attributes.
Current mechanism is via specialization. Create a new attribute. Put it in a domain module. Incorporate it into your doctype. Say so using the domains attribute. Processing system should be able to check domains attribute to determine which attributes are legitimate for conditional processing.
Paul
Prescod (summary by MP): jam values into an existing attribute … can be
unfolded into actual attributes. But could be difficult for applications to
decode, unless highly customized for DITA. Instead, why not allow undocumented
attributes after generalization? Argue against: specialization-unaware
processing might get the generalized attributes and not know their history.
Filtering might depend on history of attributes.
Example:
Trademarking tool. Runs across all content. DTD-aware, but not
specialization-aware. Trademarks will be added before output step, but output
will be done by DITA output processor. Prior to generalization, you have a
prog-language attribute. Now you have a props attribute with a collapsed value
in it. The conditional processing (run before generalization) would recognize
prog-language as a spec of prop, and run cond processing on it. After gen, cond
processing must recognize a section of the props attribute as the basis for the
conditional processing.
Chris
Wong: are we running into the same limitations? You can currently add to
otherprops. That never took off because implementations have to dive deep into
an attribute in order to implement. The same issue comes up with the props
attribute in this proposal.
MP:
It’s still just as hard to process, but it’s easier to author, because you can
author using each attribute separately. It’s different from otherprops because
it provides a formal relationship with other attributes. This relationship
could be used for re-specialization from props into multiple attributes if the
processing is too hard in the more-complex generalized form.
Eliot
Kimber: processing logic is the same since the syntax is the same. You wouldn’t
want the complex syntax in the authoring environment (the specialized form,
with separate attributes).
MP:
If you want complex attribute behavior, add a new attribute. Don’t document
complex syntax for authors.
Paul
P: Most tool vendors will only support the specialized syntax. Covers the 95%
use case. Generalized form will only be implemented … probably only by the DITA
toolkit.
MP:
To enable XML editors to be conditional-aware … take on complexity. What is
hard about it?
Paul
P: It’s DITA-specific. You need to put DITA logic into “the binary” … the core
of the editor. For example, Frame has special code to color-code certain text. That
would be necessary in tools for DITA … this could not be done by configuring.
Chris
Wong: Also, what about conflicts between values ?
Eliot:
… If I want to have a generic DITA editor that will handle any attribute, I
have to parse the domain attribute, and then dynamically configure my system
with the appropriate attributes.
Paul
P: most editors will ignore the declarations and expect a proprietary
configuration file
Eliot:
Right. Wouldn’t expect to be able to present an arbitrary new file and have the
editor recognize it. You’ll probably have to do manual configuration on the
editor, for each specific set of cond processing attributes.
Paul
P: Leads to a question of why to put the declaration info into the domain
attribute.
MP:
We can have this in the publishing pipeline and not in the editors, because the
publishing pipeline is (pardon the comparison) more configurable.
Paul
P: Configuration file is like the DITAVAL file. Would the config file not read
from the domains attribute?
Erik
H/Paul P: Specialize a condition against a specialized attribute … what happens
then?
You
could specialize two attributes from one. What happens to the lists of values?
Dana
Spradley: No objection as a proposal, but it does seem to bring up
contradictions.
Inheritance
with specializations as in Java. Every specialization can be transformed into
every other. Seems to be an inclination to make the DITA hierarchy an is-a
hierarchy rather than an is-like-a hierarchy.
MP:
to compare with OOP, in OOP, the data and the behavior live together. The
separate of data from behavior is the core attribute of an XML architecture.
MP:
need to restrict the kinds of inheritance you can do to those that have
ancestors in both hierarchies (data and behavior).
Paul
P: Back to further specialization of specialized attributes. Should we clearly
prohibit it until we are ready?
MP:
Can talk to a use case.
Eliot:
Purpose? Identify those attributes that are cond processing attributes VERSUS
specialize and know what happens with the values.
MP:
Walk through an example.
Platform
is currently an attribute w semantics … the platform that the thing we’re
documenting runs on.
Specialize:
Platform -> HW, OS, Required sw.
Those
three things combine to give Platform, but they’re not an is-a hierarchy. They
are independent aspects of the platform. What happens if someone tries to
DITAVAL against something in the Platform attribute?
Answer:
if the value in the DITAVAL file is from a specialized form, then to refer to
it in the Platform attribute, it would have to be appropriately qualified. So
HW(Z-system) is valid against Platform, corresponding to Z-system against HW.
Paul
P: Do you gain anything through the specialization to HW, OS, Required SW?
Eliot:
Can’t predict what the values of the specialized attributes would be. Just
string values that you can match on.
Erik
H: Should be able to
Eliot:
Example HW=”intel” OS=”win95”
Erik
H: should be able to find both values in Platform.
Distinguish
specialization process for attributes and separately for values.
Paul
P: does the list of values end up flattened?
MP:
intended use is to specify in the specialized attribute
Erik
H: suppose two orgs. One has specialized HW, OS, …
If
content is sent from specialized org to the org that has not specialized, the
filtering should work in the org that has not specialized.
Paul
P: now the two orgs have different data models. Hard to imagine that the two
orgs would interoperate at the value level.
Erik
H: disagree. Can process specialized content by adding to the DITAVAL file in
the not-specialized org.
MP:
Suppose 3 vals for HW, 3 vals for OS.
Ship
to not-specialized org. Suppose they want to exclude Platform=”win95 linux”.
Two sets of attributes jammed into one. Need to be able to match.
Don
D: chair observes time check.
Paul
P: separate meetings
MP:
thanks for the intense discussion. When to meet?
MP to propose after 11AM Eastern US, for 2-3 hours, others to answer by e-mail.
How
to handle references from DITAVAL to values in base class attributes. Should
they also match values in attributes from that base class?
Are
all processes require to honor the generalized syntax (cram into one
attribute), or is it for processing only?
Use case discussion …