MEETING MINUTES -- 4 JAN 2005 -- DITA TECHNICAL COMMITTEE

[Don Day <dond@us.ibm.com>]

Courtesy France Baril,

** AGENDA **
------------

1. Roll call

2. Review/approve minutes from 14 December
http://lists.oasis-open.org/archives/dita/200412/msg00033.html

3. Specification status (look for recent updates in file area)
- namespaces and identifiers: need agreement on namespace urls and
conventions for extension, and public identifiers for dtds/schemas
- naming conventions and file extensions - I'm assuming we do need to
document what the transforms will support - please check; also,
should we copy the specialization naming conventions here? finally,
should the specialization rules actually care about rules for
shell documents? they don't affect reuse, and may be the interface
to other systems that have their own naming conventions.
- topicref/link atts: how/where to talk about query, and why is it
available in map but not topic?
Also vice versa question for @translate, @xml:lang atts, which are
available in topics but not maps
- reconciliation of metadata elements in topics versus maps. should
we just defer to post-1.0?
- specifics for otherprops - how to process it (if it is really going
to function as extension, needs to be more than just a fourth
attribute - needs to allow groupings of values)
- limits of specialization - review, currently point-form only for
extension info
- namespaces in design: to be written
- developing processes: to be written
- CSS fallback support: Don to get back
- namespaces in processing: to be written

4. List issues (triage as potential post-1.0):
- Additional bugfix issues (details to come):
9. Add tm into keyword content model to enable proper trademarking
of keyword content.

10. Map and topic cannot share same keyword definition: recommend
cutting the keyword element declaration from meta_xml.mod and
paste separate defs into map.mod (no tm) and topic.mod (with
tm).

11. Elements derived from keyword must have same content models--
need to revert words.cnt back to "PCDATA" for:
msgnum, cmdname, varname
option, parmname, apiname, kwd
wintitle

12. Default attribute values must be declared with " delimiters

- Should <tm> allow images or logoized content?
http://lists.oasis-open.org/archives/dita/200411/msg00024.html

- Should <keyword> be allowed to nest?
http://lists.oasis-open.org/archives/dita/200411/msg00025.html

5. AOB?

** Minutes **
-------------

1. Roll call
- We have 9 out of 19 => No quorum
- Will make tentative decision to be accepted next week or to move to the discussion list
2. Review/approve minutes from 14 December
- No quorum, to do next week
3. Specification status (look for recent updates in file area)

- namespaces and identifiers: need agreement on namespace urls and conventions for extension, and public identifiers for dtds/schemas

Do we need them? Eliot says no, we can use system id only.

Don: since DTD has info in it, that’s providing info that’s optional and normalized. ?? Propose we have a version number in there.

Eliot: XML stds makes them unrelevant.

Don: some of the users on the call do use them, it makes sense to provide it for those who need it.

Don: Put off for 2.0?

Michael: Need agreement on what they are gonna be.

Don: look at DocBook DTD and use OASIS enterprise name that they used? Anything that needs to be resolved will have a public identifier.

TODO: Don, will provide a list of each of the modules that have a revised pi.

Don: we agree that’s in v.1.0.

Michael: NS URI for DTD and schema arch version should it actually be something like ditaarch version.
Erik Ennum: says would make sense.

NS URI itself: Eric proposed dita.oasis.org….arch1.0
Base for all ns uri will be the same
Michael: right
Eric: or oasisopen.org/dita/… arch1.0
Michael: happy with dita.oasisopen.org with dita at the front.
Eric: expectation of what follows that is version number followed by slash 1.0.org
M: do we need /arch?

E: it depends if there are other properties then arch, like doctypes and modules.
M: dita.oasisopen.org/1.0/ (EVERYONE AGREES ON THIS – Tentative decision)

URI for each of dtds and schemas:
E: to avoid collisions:
· Dita.oasisopen.org/1.0/mod/
· Dita.oasisopen.org/1.0/dtd/
M: no need for modules. Now move to 2.0
Don: Michael take it to mailing list.

Michael: TODO: Erik please put together proposal for Ns for Michael

  - naming conventions and file extensions

M: transforms are going to handle extensions. So we have naming conventions on content side to discuss.

M: Copy the naming conventions in a single place, bring spec ext in section naming conventions and file extensions? Or have them in multiple places. Will do with conref. Will see them in multiple places and them in intro doc.

M: We have naming conventions: shell files are interface and mod are reused. People might have their own naming conventions as far as what they use in their org. So maybe there is no use for us to provide naming conventions for shells and maybe contradict user conventions.

Most people who have implemented it have no issue with this.

Erik says the only thing or processing scripts care about are naming conventions for.mod files.

M: Topic type and domain modules have conventions and processing. We are documenting naming conventions for the shell. But we don’t have processing, it does not increase reuse or anything, so we don’t need to impose naming conventions on shell files.

M: will remove naming conventions for shell doc types. Tentative decision.

  - topicref/link atts: how/where to talk about query, and why is it
    available in map but not topic?
    Also vice versa question for @translate, @xml:lang atts, which are
    available in topics but not maps

Tentative decision: Need to add them in formal update of the dtd.

  - reconciliation of metadata elements in topics versus maps. should
    we just defer to post-1.0?
  - specifics for otherprops - how to process it (if it is really going
    to function as extension, needs to be more than just a  fourth
    attribute - needs to allow groupings of values)

The section on conditional processing does not give best practices for using this att. Specific additional syntax. As C. Wong raised on the list: we don’t have a std to extend attribute. But we don’t have specific syntax if we add more then 1 attribute in there. Need for 1.0 or later? Put this on the list for discussion.

  - limits of specialization - review, currently point-form only for
    extension info
  - namespaces in design: to be written
  - developing processes: to be written
  - CSS fallback support: Don to get back
  - namespaces in processing: to be written

** TENTATIVE DECISIONS **
-------------------------
Namespace URI: dita.oasisopen.org/1.0/

Naming conventions will be removed for shell doctypes.

Need to add query, translate and xml:lang attributes in the formal update of the map dtd.

** New Actions **
-----------------
Don, will provide a list of each of the modules that have a revised pi.


Erik please put together proposal for Ns for dtds and modules (if necessary) for Michael.

Otherprops: The section on conditional processing does not give best practices for using this att. Specific additional syntax. As C. Wong raised on the list: we don’t have a std to extend attribute. But we don’t have specific syntax if we add more then 1 attribute in there. Need for 1.0 or later? Put this on the list for discussion.

All: take a look at the limit of spec topic. It’s all new content and in need of review.