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

DITA Technical Committee website:  
    - Public:
    - Members only: http://www.oasis-open.org/apps/org/workgroup/dita/

- Roll call
    - We do have quorum

- Review/approve minutes from previous meeting:
    - http://lists.oasis-open.org/archives/dita/200511/msg00076.html
(Nov 15)
    - Don moves to accept minutes as read, Sharon seconds, no
      objections, approved by acclamation.

- New issues:
    - New template for 1.1 (review ideas still out)
        - We'll skip this for now, nothing to discuss
        - *** Action for Don, Bruce Esrig:  To have a proposed
          template for next week
    - Clarification of chunk attribute (see below)
        - Erik Hennum posted an update, not keyed into any
          particular numbered issue.
        - Don thinks it is editorial commentary that can be added to
          the spec itself.   Erik's not here to discuss anyway.
            - But should we take this off the numbered list of
            - Do we need to have any discussion on this today?
            - JoAnn -- WHich item is it?
            - Don -- The last item on the list of the unnumbered
              proposals --

- Issues tracking:
    - Features list
    - Definition of Status Phases:
        - In Progress:  Author(s) still working on proposal
        - Submitted:  Proposal has been submitted to TC for
          consideration; needs TC decision (vote) in order to
        - Proposal Approved:  TC has approved the proposal; authors
          working to complete the design
        - Design Approved:  Final design of the proposal has been
        - Postponed:  Proposal has been postponed to post-1.1.

- Design Approved:
    - # 9 New DATA element
    - #12 Make universal attributes completely universal

- Proposal Approved:
    - #20 Extensible metadata attributes
    - #11 Create elements for text attributes with translatable text
    - #40 Keyref architecture
    - #23 Embed version numbers into catalogs
    - #45 Add See, See Also indexing elements
    - #45a Add sort order indexing elements
    - #45b Add page range indexing elements
    - #34: Constraints - restriction without specialization

- Submitted:
    - #38: Bookmap / bkinfo revision

        - DISCUSSION copied here from TC Meeting 15 Nov 2005:
            - Don -- Highest-rated item on our list.  We need to make
              a decision here so we can move on -- there's a lot of work
              to do here.
            - Don -- Are we headed in the right direction?
            - Michael -- Are we replicated metadata that already has
              a home somewhere else?
            - Don -- If it's part of the *book* metadata, then it has
              value, so that people harvesting the metadata don't have
              to look for it in two places.
            - Michael -- bookmeta is a specialization of topicmeta,
            - Don -- Yes.
            - Michael -- Do we now have a publisher metadata element?
            - No time to continue discussion
            - ACTION for Don, Michael, Erik Hennum -- Continue the
              discussion on the list.

        - Discussion continuing today -- 
            - Don -- If there is an existing metadata element in the
              design but it's not adequate.
            - Bruce -- Is there a good summary of the bookmap
              proposal?  Can it be reposted?  Many of the details of
              the proposal are referred out to the DITA Open
              Toolkit.  Bruce hasn't been able to chase back to the
              details.  Also, there are references to a newsgroup?  
            - Don -- That newsgroup later became the DITA Users
              Group (Yahoo groups), but those references are lost
              links now.
            - Action for Don -- Get the linked material from Erik
              Hennum and post it somewhere to make it available.
            - Bruce -- Also, if we drop bookmap attributes now we'll
              introduce backwards incompatibility
            - Don -- We can't remove the attributes in an
              architected way.  Thus the proposal is to eschew their
              use and point users to do their metadata to the book
              element.  Whenever we have legacy-migration issues,
              perhaps there should be (as part of the design
              document) a discussion about migration.
            - Bruce -- This is a case of something outside the spec,
              but commonly used as though it's part of the spec.  So
              we would not be obligated to do this, but it would be
              a service.
            - Don -- In terms of moving forward to getting this to
              design, let's say that the design document will
              discuss several migration scenarios for existing
              content.  Does that sound OK?
            - Bruce -- Yes
            - Don -- The TC itself is not responsible for developing
              tools, but we'll ask tool vendors to help support
              migration.  The Design Document can suggest some best
              practices for the implementers to do that.
            - Don -- What cases of existing content do we need to
              consider to see what kinds of migration issues there
              will be for users and vendors?
            - Chris Kravogel -- We are using bookmap with clients.
            - JoAnn -- No concerns right now, but it's a significant
              change nonetheless.  People are more interested in
              having a "better bookmap", to avoid having to do so
              much customization.
            - Jen Linton -- Let's put a note out on the DITA Users
              list to capture people's requirements.
            - *** Action for Don -- post that on the DITA Users
              List, asking who is using DITA map and what their
              migration requirements will be.  Capture that as an
              addendum for the proposal, so we have additional
              context for making a decision.
            - Paul Prescod -- Are we really just adding additional
              book capabilities to DITA?  
            - Don -- This is more about the formal ...  (couldn't
              catch all this!)
            - Paul -- Perhaps we should call it "Add book-level
              processing to DITA based upon revised bookmap demo" --
              new title for the proposal.
                - Doesn't want to force a large-scale rewriting, but
                  we might want to write the proposal from this
                  point of view -- for example, giving more
                  references to what the existing bookmap is, to
                  provide context for people to understand what we
                  are voting on.
            - Chris Kravogel -- We have used the bookmap pretty much
              unchanged, except for bookinfo metadata.  THere is
              a reason why he is on the bookmap team -- to really
              follow what is happening there, so they can be ready
              to make necessary changes for their customers.
            - Don -- It's good to have you there, to capture your
              experience with using bookmap with customers.
            - Don -- Any other discussion?
            - Paul -- Just one more thought -- The scope of the
              work, and the scope of the 1.1 spec, is going to be
              quite substantial.  Does this really need to go into
              base DITA?  Maybe it doesn't necessarily need to be
              part of the base spec with the topics.
            - Don -- Has also wondered about this.  How do we
              differentiate between the core spec, and useful
              hierarchical additions to that core?  "Blessed"
              buildout from that core?
                - Maybe that's not a decision for today -- can we
                  state it in terms of general principles?
            - Paul -- Some DTDs and schemas will be
              industry-specific, that we wouldn't want to put into
              the core.  
            - Don -- Acknowledging the concern, but not identifying
              a decision or a specific direction.
                - Let's add an item to the non-numbered section of
                  the things we need to discuss, to resolve this
                  question.  Action for Don ***.
            - Conclusion:  Action for Don to do a rewrite of the
              bookmap discussion so we can make a decision next
    - #32: Domain and topic integration
        - Skipped since Erik Hennum isn't here.

    - #8: Allow tm to contain images or logo content
        - Owned by Chris Kravogel.
        - Don -- Within IBM, we do a word-scan of the content of the
          document, to compare words to known trademark lists.  The
          scanning tool identifies them and marks only the first of
          multiple occurrences.  It's completely dependent on the
          existence of discoverable text.  This particular tool
          would not be able to scan against the existence of
          a graphic tm element.  Thus, part of the proposal needs to
          look at how others might be processing these things.
        - Bruce -- The standard way of doing this, is to indicate
          the text together with the graphic.  This would allow you
          to identify the trademarks contained in the document.  
        - Don -- How do we implement the binding between the graphic
          and the text element?  Typos, etc.
        - Paul Prescod? -- IBM is "IBM" as text, and "IBM" as
          graphical logo.  This is at the heart of the matter.
        - Chris -- That's an issue for the reviewer to check.
        - Don -- This is one case where the design and processing
          impinge on the authoring.  Can we associate the *graphic*
          to the tm list, so that the *tool* binds the image to the
          processing, rather than making the author do that?
        - Bruce -- He was envisioning that this would be done by
          preprocessing tools.
        - Chris -- We could have both possibilities, depending on
          what kinds of rules the company / author decide on.
        - Bruce -- The text strings could be post-processed
          depending on whether the users set things up that way.
        - Paul Prescod -- Did IBM add this element primarily to get
          the output effect of generating TM characters?  Or is
          there more to it than that?
        - Don -- It generates a properly trademarked character.  It
          can also be inserted manually, or be done by a tool.  This
          also ensures that the terms are correct.
        - Paul -- If the real goal is the element is to generate an
          appropriate trademark symbol, associated with some text,
          then it seems that the simplest proposal is to add the
          image to the content model for the trademark.  But if
          there are use cases where we need to generate summary
          lists (etc.), we might need to address that issue too.  
        - Seraphim -- Easy to envision a use case where you need to
          summarize all the trademarks that occur and put them on
          a "legal disclaimer" page (for example).
        - Don -- Also, there will be users who don't have an
          automated system like that, and need to do everything
        - Rob Frankland -- There are cases where a customer's
          trademark is not text, but is some kind of graphic.  
        - Don -- But even those graphics are often encoded as
          UNICODE code points.
        - Paul -- And there are use cases where there are both
          graphical and textual trademarks.
        - Don -- Perhaps we need a few more use cases.  We don't
          have a clear picture of exactly what we're thinking of
          doing with this.  
        - Action for Chris -- to discuss this with Robert Anderson
          at IBM to look at IBM's use case.
        - Action for all -- Send trademark use cases directly to
          Chris Kravogel <christian.kravogel@seicodyne.ch>
        - Don suggests also for Chris to consider this form: <image
          href=""><tm attrs...>IBM</tm><alt>IBM Logo</alt></image>
          This has the advantage of not creating any new markup, of
          not introducing image within keyword (which is what image
          within tm would imply), and of ensuring that tm can occur
          anywhere that you would want to place a logo anyway (that
          is, anyplace in which image is already allowed).  There is
          little difference in terms of processing for output, and
          it retains the advantage of string searching for text of
          interest for policy-enforcing tools, and works fine for
          direct authoring.
        - Additional commentary from Bruce Esrig, following the
          meeting -- 
            - The basic proposal seems to be to allow graphics to
              appear in output as a result of trademark markup.
            - We are unresolved about why this is helpful, and if it
              is helpful, what features to support.
            - To respect the rights of copyright holders, the first
              occurrence of a trademark should be marked.
            - Some authoring environments might seek to automate
              this marking. In such environments, the markup would
              be added through some sort of processing, either to
              clean up the source in order to make sure it is ready
              for production, or to automatically add trademark
              indications during processing. The same processing
              could extract the names of the trademark owners for an
              auto-generated list.
            - The USPTO (US Patent and Trademark Office) has a field
              that can hold equivalent text for a graphic. This
              permits a blue graphic that looks a little like "IBM"
              to be associated with the text "IBM". Automatic
              processing could ... report a reference based on the
              alternate text or based on another text string ("IBM"
              or "the IBM logo") and credit the owner ("is the
              property of ..."). However, we might ask whether
              a generic statement would be sufficient. A generic
              statement is sometimes used to cover the use of
              trademarks ("... their respective owners").
            - A graphic would usually contain the appropriate
              trademark symbol (in the US, this is a circle-R if
              either a trademark or service mark is registered).
              Therefore adding the trademark symbol may not be
              suitable. The trademark markup would simply serve to
              flag a use of a particular graphic which is
              a trademarked symbol.
            - Note another complication. If a trademark is used
              WITHIN a large graphic, would it be necessary to have
              non-printing markup to declare the trademark? Or is
              there metadata for a graphic that could be used for

        - Additional commentary from Don Day, following the meeting -- 
            - I think there is a true semantic distinction between
              trademark text (the discoverable thing that takes the
              (TM) or (R) superscript qualifier) and a logo, which
              is not ordinarily used in discourse (as with "XML" in
              "DITA is an application of (Embedded image moved to
              file: pic22036.jpg) ") (FYI, there is a graphic [XML]
              at the end of that sentence).  Legal experts might be
              even quicker to point out the distinction between the
              two.  The graphic might be an output expression of
              a full trademarked string, but anyone searching
              a document for trademark infringement will be doing
              the string analysis anyway.  Even in the output, the
              text of the tm should go into the @alt="XML logo"
              attribute for the image.
            - (And the fact that IBM uses logos such as [eServer] in
              discourse all over the Web informs me that there are
              cases for such usage--I'm just trying to find the best
              practice for separating source from output concerns.)

    - #5 Add ANSI warning labels as addition to element
    - #19 Introduce new, more general task type
    - # 4 Use subset of OASIS xNAL standard for addresses
    - # 6 Make @role (and other enumerated attribues) unenumerated
    - #17a Conref - improved specialization support
    - #17b Conref - with delta (applying changes)
    - #17c Conref - referencing a range of elements
    - #17d Conref and conditional processing - preserve without
    - #17e Conref - push instead of pull
    - #42 shortdesc flexibility (includes #41)
    - #43 Semantic (implicit) linking
    - #35 Support foreign content vocabularies such as MathML and
    - #14 Specialize glossary entry and definition elements
    - #2 Keywords in keywords
    - #00 Nested Sections Solution Proposal

- In progress:
    - #47 Structured Sections (replaced by "Nested sections proposed

- Postponed to Post 1.1:
    - #37 Reconciling topic and elements

- Post 1.1: everything else

- Spec and process issues (from Yas's notes, other comments):
    - Update DITA 1.0 DTD/Schema specification (bug fixes and comment
    - http://lists.oasis-open.org/archives/dita/200507/msg00058.html
among others

Naming convention
http://lists.oasis-open.org/archives/dita/200509/msg00024.html (approved

OASIS artifact naming guidelines (to follow where applicable)

Relax the related links content model so it can be empty (more of a fix
Meeting-Minutes-04-October-2005.txt (approved for 1.1 timing)

Documenting DITA design principles (not approved yet)

Details in the DITA spec--Priestley ("There are some cases...
where the spec needs to be updated")
- behavior of conref with attributes on the referencing element
- why a content fragment has to be addressed within a topic

Styling options for conditional text
Recognizing DITA documents

New worked proposals (unnumbered) from members:
Extensibility of DITA through new attributes
http://lists.oasis-open.org/archives/dita/200508/msg00069.html and

Styling Options for Conditional Text
http://lists.oasis-open.org/archives/dita/200508/msg00066.html and

Recognizing DITA Documents
http://lists.oasis-open.org/archives/dita/200508/msg00067.html and

Start of documenting DITA design principles (Paul Prescod)

Module Registry proposal (Bruce Esrig)

Clarification of Chunk attribute (Erik Hennum)


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]