[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: MEETING MINUTES -- 29 November 2005 -- DITA TECHNICAL COMMITTEE
MEETING MINUTES -- 29 November 2005 -- DITA TECHNICAL COMMITTEE
(Minutes taken by Seraphim Larsen <seraphim.l.larsen@intel.com>)
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/
- 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
issues?
- 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 --
http://www.oasis-open.org/apps/org/workgroup/dita/download.php/15374/Chu
nk.html
- 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
proceed.
- Proposal Approved: TC has approved the proposal; authors
working to complete the design
- Design Approved: Final design of the proposal has been
approved.
- 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
http://www.oasis-open.org/committees/download.php/15056/IssueNumber38.ht
m
- 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,
right?
- 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
week.
- #32: Domain and topic integration
http://www.oasis-open.org/committees/download.php/14849/Issue32.html
- Skipped since Erik Hennum isn't here.
- #8: Allow tm to contain images or logo content
http://www.oasis-open.org/committees/download.php/15055/IssueNumber08_.h
tm
- 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
manually.
- 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
this?
- 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
http://www.oasis-open.org/committees/download.php/15057/IssueNumber5-haz
.htm
- #19 Introduce new, more general task type
http://www.oasis-open.org/committees/download.php/15058/IssueNumber19-ta
sk.htm
- # 4 Use subset of OASIS xNAL standard for addresses
http://www.oasis-open.org/committees/download.php/15112/IssueNumber4.htm
- # 6 Make @role (and other enumerated attribues) unenumerated
http://www.oasis-open.org/committees/download.php/15115/IssueNumber06.ht
ml
- #17a Conref - improved specialization support
http://www.oasis-open.org/committees/download.php/15116/IssueNumber17a.h
tml
- #17b Conref - with delta (applying changes)
http://www.oasis-open.org/committees/download.php/15117/IssueNumber17b.h
tml
- #17c Conref - referencing a range of elements
http://www.oasis-open.org/committees/download.php/15118/IssueNumber17c.h
tml
- #17d Conref and conditional processing - preserve without
resolving
http://www.oasis-open.org/committees/download.php/15119/IssueNumber17d.h
tml
- #17e Conref - push instead of pull
http://www.oasis-open.org/committees/download.php/15120/IssueNumber17e.h
tml
- #42 shortdesc flexibility (includes #41)
http://www.oasis-open.org/committees/download.php/15121/IssueNumber42.ht
ml
- #43 Semantic (implicit) linking
http://www.oasis-open.org/committees/download.php/15122/IssueNumber43.ht
ml
- #35 Support foreign content vocabularies such as MathML and
SVG
http://www.oasis-open.org/committees/download.php/15123/IssueNumber35.ht
ml
- #14 Specialize glossary entry and definition elements
http://www.oasis-open.org/committees/download.php/15140/Issue14.html
- #2 Keywords in keywords
http://www.oasis-open.org/committees/download.php/15522/IssueNumber02.ht
ml
- #00 Nested Sections Solution Proposal
http://lists.oasis-open.org/archives/dita/200511/msg00084.html
- In progress:
- #47 Structured Sections (replaced by "Nested sections proposed
compromise")
http://lists.oasis-open.org/archives/dita/200511/msg00067.html
- 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
edits)
- 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
2005-09-30)
OASIS artifact naming guidelines (to follow where applicable)
http://lists.oasis-open.org/archives/dita/200507/maillist.html
Relax the related links content model so it can be empty (more of a fix
issue)
http://lists.oasis-open.org/archives/dita/200509/msg00050.html
(proposal)
http://www.oasis-open.org/apps/org/workgroup/dita/download.php/14855/TC-
Meeting-Minutes-04-October-2005.txt (approved for 1.1 timing)
Documenting DITA design principles (not approved yet)
http://lists.oasis-open.org/archives/dita/200510/msg00005.html
Details in the DITA spec--Priestley ("There are some cases...
where the spec needs to be updated")
http://lists.oasis-open.org/archives/dita/200510/msg00059.html
- 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/msg00065.html
http://lists.oasis-open.org/archives/dita/200508/msg00069.html and
following
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
Recognizing DITA Documents
http://lists.oasis-open.org/archives/dita/200508/msg00067.html and
following
Start of documenting DITA design principles (Paul Prescod)
http://lists.oasis-open.org/archives/dita/200510/msg00005.html
Module Registry proposal (Bruce Esrig)
http://lists.oasis-open.org/archives/dita/200510/msg00097.html
Clarification of Chunk attribute (Erik Hennum)
http://lists.oasis-open.org/archives/dita/200511/msg00070.html
<end>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]