[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] DITA Technical Committee Meeting Minutes: 31 October 2006
Hello, Yas was seeking some clarification on the use of the class attribute in a foreign element specialization. The specialization method that we recommend folks using for DITA 1.1 for incorporating foreign vocabularies is to have a wrapper element to incorporates the namespaced foreign content. Since the wrapper element is a specialization of <foreign> or <unknown>, therefore a DITA element, it must a have a class attribute ( <!ATTLIST svg class CDATA "+ topic/foreign svg-d/svg " > ). The elements defined within the foreign vocabulary are non-DITA elements, so, there is no requirement to have a class attribute for each of the elements. Hopefully, adding a statement or paragraph in the foreign content specialization topic explaining which elements require a class attribute and those that do not is sufficient for everyone. As for updating the specialization samples in the spec, I don't that is required. If someone disagrees, we can discuss what info should be in the sample (adding some of the normalized class attributes in the sample??) Kind regards, Eric Eric A. Sirois Staff Software Developer DB2 Universal Database - Information Development DITA Migration and Tools Development IBM Canada Ltd. - Toronto Software Lab Email: esirois@ca.ibm.com Blue Pages (Internal) "Transparency and accessibility requirements dictate that public information and government transactions avoid depending on technologies that imply or impose a specific product or platform on businesses or citizens" - EU on XML-based office document formats. Don Day <dond@us.ibm.com> To 11/07/2006 01:29 "Grosso, Paul" <pgrosso@ptc.com> PM cc dita@lists.oasis-open.org Subject RE: [dita] DITA Technical Committee Meeting Minutes: 31 October 2006 I appreciate the suggestions about the IP selection process, Paul. Let's try the approach you suggest. And it need not even be right away--we are just getting OASIS nag notices to have our election done by April--plenty of time. I'll summarize all the fleshed-out amendments to go with the minutes when we review them next meeting. For the action on the foreign element discussion, I propose this amendment: ACTION: Eric Sirois to provide an updated example and brief discussion on using the class attribute with foreign attributes; to be incorporated as an example into the spec topic for the <foreign> element. Regards, -- Don Day Chair, OASIS DITA Technical Committee IBM Lead DITA Architect Email: dond@us.ibm.com 11501 Burnet Rd. MS9033E015, Austin TX 78758 Phone: +1 512-838-8550 T/L: 678-8550 "Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?" --T.S. Eliot "Grosso, Paul" <pgrosso@ptc.com> To 11/06/2006 06:24 <dita@lists.oasis-open.org> PM cc Subject RE: [dita] DITA Technical Committee Meeting Minutes: 31 October 2006 > > 3. ITEM: Use of standardized prefixes when incorporating foreign vocabularies > * http://lists.oasis-open.org/archives/dita/200610/msg00021.html > > Yas: This feature is required for at least one editor. > > Eric clarifies: The element after the slash (e.g. class="topic/p") > should have a namespace prefixed to the p element in the class > attribute. > > General consensus: Handling of namespace attributes in DITA requires > some thought, and is already logged to be discussed in the future. > > Yas asked for example of how to correctly incorporate foreign > vocabulary on the list that we can then discuss on the list. > > Don summarizes: It's a documentation issues and we just need to > define an example of how to handle the class attribute with foreign > attributes. Therefore it's a non-issue for the TC. What is the action item here? If it's an issue at all, I'm unclear on how it is a non-issue for the TC. It might not be something we need to address in the 1.1 spec, but if it's an issue, the TC needs to address it, and there needs to be an action item. > > 4. ITEM: Versioning of DITA public identifiers > * http://lists.oasis-open.org/archives/dita/200610/msg00025.html > > Paul G: Version and non-version specific versions of DTDs, with > catalog used to locate the correct DTD. > > Robert: TC needs to declare the public IDs to be used. > DECISION: Robert moves to change DITA version attribute from text to > data and to define version-specific IDs in the catalog. Scott > seconds. No objections. Clarification to the minutes: Instead of "from text to data", we are removing the "#FIXED" indication from the (already CDATA) DITAArchVersion attribute. More precisely, I'd phrase the decision as follows: DECISION: Robert moves to remove the "#FIXED" indication from the DITAArchVersion attribute and to include version-specific FPIs (formal public identifiers) in the catalog. Scott seconds. No objections. > > 8. ITEM: IPR Transition > * http://lists.oasis-open.org/archives/dita/200610/msg00075.html > (request from Mary McRae) > > To be discussed next meeting. > > Don: We're leaning towards royalty free options. We need to make our > decision shortly. We'll have extended discussion next meeting. I object to having an extended discussion of this during the telcon. I would much prefer to spend TC telcon time working on the technical DITA 1.1 issues. I would like to propose (and I will so move at the beginning of the telcon) that we open the IPR transition issue by asking if there are any objections to going with OASIS' standard RF option (as the DocBook TC and others have done). If there are objections, those objecting can start an email discussion about it. If there are no objections, we can task someone (Don?) to draft the necessary documents offline, and then we can vote on them. There is nothing I'd like to avoid more than wasting telcon time talking about IP issues. paul
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]