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