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]


(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:
    - 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
        - 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:

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

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

- 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 


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]