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]


Subject: Groups - DITA TC Meeting Minutes 18 February 2014 uploaded


Submitter's message
Action Items:
1.Robert will update definition of @keyref (left over from pre-1.2) on map container elements.
2. Robert will make changes to spec or code, as decided by TC, on various L&T elements.

==================================================
Minutes of the OASIS DITA TC
Tuesday, 18 February 2014
Recorded by N. Harrison
link to agenda for this meeting:
https://wiki.oasis-open.org/dita/PreviousAgendas

regrets: Bissantz, Hudson

Standing Business
=================
Approve minutes from previous business meeting:
https://lists.oasis-open.org/archives/dita/201402/msg00125.html (11 February, Nancy Harrison)
Proposed by Kris, seconded by Dick, approved by TC

Subcommittee Reports
none

Announcements
none


Business
========
1. DITA 1.3 progress
- Incorporating proposals into spec: 36 of 37 completed (Eberlein)
- First editorial pass completed: 29 of 37 completed (Eberlein)
- Attributes rework (Anderson):
- Robert; finished all of base and techcomm, and worked on L&T

- Review tool availability: Estimated for 12 February 2014
- Kris; met with Nancy & Joann; we don't yet have a completely function DITAWEB, but we should soon.

- RelaxNG-to-DTD and RelaxNG-to-XSD transformations (Kimber)
- Eliot has DTD and XSD transforms done, and started setting up automated testing server to do testing; expect to generate all docs and validate them (still working on that, but very close). He'll be able to automatically do regression testing; any time there's a change to RNG code, will run all trasnforms, run all tests and produce error/validation messages.
Kris; you were confident you'd have 1.3 grammar files by 3/1; is that still true?
Eliot; yes, I still expect to do that by that date
Kris; do you need any help from TC?
Eliot; no, Scott has provided a large set of test docs; I'd be happy to get more of those; but otherwise, no other help needed.

- Omnimark transformation for implementing the XML mention domain (Bob Thomas)
Kris; met with Bob Thomas re plugings an stylesheets
Bob; effort seems pretty straightforward


2. New item (but continued from last week): Proposed enhancement to the equation domain
- Eliot brought the TC up to date: he contacted Dr Leaven at Imperial College (London); Leaven said that for scholarly mathmeticians, the question of whether an equation is preented inline or block is independent of the structure of the equation; they present it as a block only if they need to number it later, or if it's really complicated. They might even go so far as having a period at end of equation if it comes at end of sentence. So the current 1.3 equation domain just doesn't meet their needs; it doesn't give info on whether it's inline or block; it's specialized from . so we need an element to hold the number, as well as signaling that a number is needed. Eliot would like to use @outputclass values, since they can show up in text, or in a subjectscheme.
- Joann; sounds like there are just no rules
- Eliot; they're academics, thinking up new stuff
- Don; can we tie this to an id value somehow?
- Eliot; no, you might want an id on an equation, even if you don't want to number it.
- Don; generality principle would lead us to consider whether other DITA structures need this as well.
- Eliot; we're not talking about MathML, just about 'equation', 'equation-inline'
- Tom; about numbering; you say they do have some guidelines; do we need to facilitate really hybrid situation? i.e. is there something we could do that would be more general?
- Eliot; I'm sure that TDI must have something, but I dont know
- Kris; I don't like @outputclass having particular values
- Chris; I'm similarly uncomfortable with mandating particular values for @outputclass in the spec.
- Eliot; the only other option is to have different elements within the equation domain
- Kris; I see no reason for that; we want something consistent.
- Eliot; we could also use 'data' to indicate the number, but that's less intuitive.
- Chris; @outputclas has always been an escape hatch; I don't want the TC to use it specifically
- Bob; I don't think it's overloading @outputclass; it's just giving it a specific set of values in this case.
[discussion re: attributes vs subelements. Question of "is it ever ok to define specific values for @outputclass?"]
- Kris; Eliot, can you take this to the TC list and define possibility of using 'data' subelement.
- Robert; Might this be related to the way we have @placement on the image element?
- Don; similiar; but image doesn't have a way to apply numbering to an inline element.
- Robert; we can't get @placement if we specialize from 'ph'; we'd need to have a placement @ on ph; we're definitely not going to consider that for 1.3
[move on to next item; get back when kris can talk]


3. New item: Normative statements and file-naming conventions
https://lists.oasis-open.org/archives/dita/201402/msg00133.html (Eberlein, 17 February 2014)
[postponed till Kris is on call with a good connection]


4. New item: keyref attribute on non-titled non-linked container elements
https://lists.oasis-open.org/archives/dita/201402/msg00087.html (Anderson, 14 February 2014)
- Robert; we have @keyref on 3 items frontmatter, backmatter, and booklists; they're all containers; the attribute was on all of them before we defined @keyref in 1.2. So the question is; should we just state that keyref @ on these three elements is 'undefined' and move on ?
[Eliot agreed in mail he sent in response to Robert's].
Resolution/ActionItem: Robert will update the spec to reflect his suggestion.


5. New item: Request clarification of @datatype on new lcSequence2 element
Robert; @datatype is required on this element, but it's not clearly defined, and the examples don't show it.
Questions:
1. Is this @ really defined?
2. If so, is it really required?
3. If it's defined, what sort of value does it take?
We need input from L&T SC (JohnH?) for this.
Johnh; I don't remember exactly how it got there, so if we don't see a value for it, let's remove it.
Resolution; remove @datatype from this element, with email to TC


6. New item: Errors in spec topic for lomTechRequirement element
https://lists.oasis-open.org/archives/dita/201402/msg00144.html (Anderson, 17 February 2014)
Robert gave a summary; the default values for @name in the DTD/XSD don't match the one defined in the spec (i.e. 'OperatingSystem ! Browser' vs the value for 'iomTechRequirements'), and the default values for @value are mostly useless, consisting of obsolete OS and browser names.
So there are 2 questions:
1. what to do about the discrepancy between the spec and DTD/XSD?
2. should we be hard-coding obsolete values into the spec and DTD/XSd, or should we use CDATA to allow for new values?
- JohnH; we modeled these on IEEELOM from 2002, so we can either stick with this list (it's still in use in IEELOM) or drop the explicit list and go with CDATA; if we keep a list, we need to keep whatever is there now, or can go to CDATA
- Robert; there's no way to actually define these
- JohnH; so probably we should go to CDATA
- Robert; what we really need is a better description of the meaning of the datatype attributes
- Joann; does this list include a value like 'other', so a user could use e.g., 'apple'
- Robert; we could open it up and mention that that list is what conforms to the other standard
- JohnH; the element is correlated with an external standard which is now outdated, but is still used. so we should mention that.
Resolution; make @value CDATA, and enumerate values that comply with IEEELOM standard.


7. New item: lomStructure
Robert; For this element, the spec lists more values than the DTD; which is correct?
- JohnH; actually, we should remove the extra values from the spec.
Robert; just fyi, the XSD matches spec; the DTD is constrained; so are you OK with expandng the DTD?
- JohnH; yes.
Resolution; the spec will be taken as correct, and the DTD will be expanded to list all the values.


8. New item: lomLearningResourceType
Robert; here, the default set of values for @value differ between the spec and the DTD/XSD (which are the same). In additiona to case and one work/two word issues, the spec is missing the value 'lecture'.
- John; DTD/XSD are correct.
Resolution: Spec will be updated to match implementation of @value defaults, where it's a. lowercase, b. 1 word rather than 2, and c. contains 'lecture' as a possible value.


9. New item: lomInteractivityType
Robert; here, the DTD and XSD don't list 'undefined' as a possible value for @value; do we remove from spec, or add to DTD/XSD/RNG?
- JohnH; it's not in the reference LOM spec, so we could remove it.
Resolution; remove from spec: 'undefined' as a possible value for @value


10. New item: Spec bug in inheritance section for lcLom
Robert; the inheritance section in the spec says [incorrectly] that this element is specialized from 'data'; it's actually specialized from 'metadata', and is correctly implemented that way. We need to fix the spec to give the right inheritance, and treat this as spec errata, as it actually is.
Resolution; update the spec to list inheritance from 'metadata', and list as errata.



meeting closed at 12:00


-- Nancy Harrison
Document Name: DITA TC Meeting Minutes 18 February 2014

No description provided.
Download Latest Revision
Public Download Link

Submitter: Nancy Harrison
Group: OASIS Darwin Information Typing Architecture (DITA) TC
Folder: Meeting Notes
Date submitted: 2014-02-24 23:26:43



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