[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: MEETING MINUTES -- 31 January 2006 -- DITA TECHNICAL COMMITTEE
MEETING MINUTES -- 31 January 2006 -- DITA TECHNICAL COMMITTEE
(Minutes taken by Seraphim Larsen <seraphim.l.larsen@intel.com>)
Date: Tuesday, 31 January 2006
Time: 08:00am - 09:00am PT
DITA Technical Committee website:
- Public:
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=dita
- Members only: http://www.oasis-open.org/apps/org/workgroup/dita/
- Wiki: http://wiki.oasis-open.org/dita/
- Roll call
- We do have quorum
- Review/approve minutes from previous meeting:
- http://lists.oasis-open.org/archives/dita/200601/msg00029.html
(Jan 24)
- The following snippet should be attributed to Paul Grosso
(***** ACTION for Seraphim)
- Paul -- As an aside -- how do things get added to
this list of issues (such as his graphics issue,
which he posted to the TC list)?
- Don proposes to accept the minutes as read and amended,
JoAnn Hackos seconded, approved by acclamation.
- News, events:
- Upcoming first meeting for translation liaison discussion
- First meeting will be next Tuesday (7 Feb 2006), 8-9 AM PT
(same time as DITA TC meeting) -- Don will send out
announcement
- Don -- Has anyone written any best practices on this
(elements in DITA used for translation)?
- Chris Wong -- Doesn't have any information on that.
- JoAnn Hackos -- Doesn't have anything written.
- Robert Anderson -- Robert wrote an article for this
for IBM -- see the following URL:
http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/200601/
msg00034.html
- Kris Kravogel -- Trados could not distinguish the
elements to be translated based only on attributes.
But Trados is releasing a new version of the software
that is attributes-aware.
- JoAnn -- Has heard the same thing.
- Prep for conferences starting next month
- JoAnn's CMS Conference
- JoAnn scheduled a time for the TC to have
a meeting, if it materializes
- Also have a timeslot blocked out for the DITA TC
meeting
- Also have a Q&A session scheduled
- Also have a TC member dinner scheduled
- OASIS Interoperability Symposium
- Nancy -- Erik Hennum will be presenting (but he's
not present to give details now)
- DITA 2006 (Bright Path Solutions) Conference
- No comments
- Resource: OASIS DITA Wiki
- http://wiki.oasis-open.org/dita/FrontPage
- Our previous work on items accepted for DITA 1.1 is here:
- http://wiki.oasis-open.org/dita/AcceptedAndCandidate
- Resume review of "left off the list" and unnumbered proposals for
1.1 scope:
- http://wiki.oasis-open.org/dita/OffTheList#preview
- Extensibility of DITA through new attributes (continue
discussion from last meeting)
- COPIED FROM 24 Jan 2006 meeting:
-
http://lists.oasis-open.org/archives/dita/200508/msg00065.html
-
http://lists.oasis-open.org/archives/dita/200508/msg00069.html
and following
- Don -- Is there a reason why this is not one of the
existing requirements that we've already discussed?
Isn't this already covered in the general
extensibility of attributes that is covered by another
proposal in progress?
- Michael -- There was some confusion, because Michael
was calling it metadata attributes, and did not refer
to all attributes in general. This new proposal is in
regard to all attributes in general.
- It really comes down to design principles.
Inheritance doesn't work with attributes, and to
make it work, we need to do a lot of rework.
That's possible for profiling attributes, but it's
outside of present scope to do it for *all*
attributes. General extensibility (being able to
specialize *anything*) is going to be really hard
to address.
- We might be able to handle Paul Prescod's concerns
by defining two base class attributes, one for
profiling and one for anything, and only allowing
specialization off of those two.
- Without Paul Prescod, we can't really resolve
today. So let's continue here next time.
- Discussion continued today (31 Jan 2006)
- Michael Priestley (MP) restated and clarified his
concerns.
- Paul Prescod -- How will it be done for the profiling
attribute? In the toolkit, how do you expect to
implement it? In the XSLT? As part of the filering
process?
- MP - The XSLT isn't written.
- Don - Should it be an extension to the existing
toolkit process? Or something to be implemented in
the toolkit later?
- MP - It's not an override, it's a change to the spec,
so the transforms would need to be modified. You
should be able to reference any attribute that is
a specialization of a profiling attribute, and you
should be able to do profiling off of it. It should
also work when the specialized attribute isn't present
-- the processing would be rolled up to its ancestors
and be processed accordingly. (He gave an example,
using "education level" as a specialization of the
"audience" attribute".)
- The net effect is that if you generalize
a document that had specialized attributes in it,
it won't break your processing, you will not lose
any behavior, it will follow the generalized
ancestor processing.
- Don - Are you saying, let's go ahead and work this
into the TC as a proposal?
- MP - No, we're not there yet. He just was clarifying
the current proposal (#20). We haven't yet gone to
the point of whether we want to do something similar
for a new base-class attribute, and general attribute
extensibility.
- Don - We need to parse this into two requests.
- Paul Prescod (PP) - The proposal that MP has made,
addresses the vast majority of cases that require
extra attributes.
- Overall, he feels that the new proposed model goes
to great lengths to meet needs that are not very
widely needed -- in practice, he never sees the
need for general extensibility. But if others see
different, then we can live with it.
- We can allow the model for generalizing, editing,
and respecializing.
- He'd advise his customers against that, though,
because he doesn't thinkt he authoring tools can
maintain structural validity when you have people
editing the generalized form.
- MP - It would be important mainly for reintegration of
information in a wide integration context, when you're
trying to pull together content from disperse
organizations that are merging (for example).
- Thus, it's a feature in anticipation of
a requirement.
- But it is core to the promise that DITA is
making from a business-case perspective.
- PP - OK, let's keep looking into it, and in the
meantime let's consider MP's proposal as the best
approach for now.
- He'd suggest rolling the solution into issue
#20, or at least having two separate proposals
but they need to be closely coordinated.
- MP - Agrees that it should be rolled into #20 -- it
should be an amendment to #20.
- PP - Will also contribute use cases to the new #20.
- Styling Options for Conditional Text
- http://lists.oasis-open.org/archives/dita/200508/msg00066.html
and following
http://lists.oasis-open.org/archives/dita/200509/msg00025.html
- Discussion 31 Jan 2006:
- Don - Can this proposal be extended to include print
issues, not just online issues?
- Paul Prescod (PP) - What is there in the proposal that
is considered not print-oriented?
- Don - Equivalent indication of revision, between print
and online. Online doesn't let you have change bars,
for example, so online uses colors instead.
- But it seems clear that the main proposal is to
allow a broader range of methods for indicating
conditional text.
- PP - (disagreeing with self?) - Is it in the scope of
1.1 to standardize the ditaval file? He had heard
grumblings that it might become standardized (driven
by other issues).
- MP - Yes, probably does need to be standardized as
part of the spec.
- PP - Is issue #20 getting too overloaded to also
cover this? Should we do a separate proposal to
cover it?
- MP - Item #20 currently does have that as part of
the proposal.
- Don - OK, let's move this to the item #20
discussion then.
- Don - Formalizing ditaval, then, is part of item
#20.
- PP - Does anyone feel that we need to include
these extra formatting options right off the bat?
(he listed several) These help you to see when
two or more conditions are applied at the same
time.
- Alan Houser (AH) - Question on the formatting
attributes. Seems like an implementation issue to
him. Are we saying that all authoring tools
should consistent in the way they present the
different text properties?
- Don - The author will expect something to
occur, based on the values entered. Thus we
are trying to drive agreement that
implementers should support.
- AH - Seems like an implementation detail that
should be left up to the authoring tool
vendors.
- PP - It is more relevant to the authoring tool
implementation/interface. But we do need
a way to help the authoring tools get
consistent results. It helps drive
consistency in the publishing process.
- Doesn't have a strong feeling that it must
be part of the DITA spec, but does hope to
see that the tool vendors can agree on the
approach.
- Alex Povzner - Shouldn't it be handled in the
style sheets, if it's just a styling issue?
- Chris Wong - ditaval does determine the output
content, as well as a suggestion for
formatting options. (So, it's not just
limited to formatting/appearance).
- Don - Is this related to proposal #39?
- Robert - Thinks that Erik Hennum wanted to
keep the formatting separate.
- Don - Should ditafile create any more handles
for processing? Maybe we should look at style
control to be controlled through an external
style sheet?
- PP - The policy-based style is an
off-the-list item?
- PP - Summary - We should standardize
ditaval... (couldn't capture all comments)
- MP - Can roll this into issue #20.
- Don - All the items implied by this particular
discussion, then, are to be moved to issue
#20. We just moved it into the scope of item
#20.
- Let's roll up the decisions on the off-the-list items -- *****
ACTION Seraphim and Don to meet and summarize these for a vote.
- Next week -- resume with the "Off the List" list
- http://wiki.oasis-open.org/dita/OffTheList
- Resume here -- Recognizing DITA Documents
<end>
___________________________________________________________
Seraphim Larsen CIG Operations / TPPE
Senior Technical Writer Intel Corporation
(480) 552-6504 Chandler, AZ
The content of this message is my personal opinion only.
Although I am an employee of Intel, the statements I make
here in no way represent Intel's position on the issue, nor
am I authorized to speak on behalf of Intel on this matter.
___________________________________________________________
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]