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 20 March 2018 uploaded


Submitter's message
ActionItem:
1. Robert will check the spec to see if language on the purpose and appropriate usage of @otherprops is there, and include the requirement for that language in the stage 3 proposal.


=================================================
Minutes of the OASIS DITA TC
Tuesday, 20 March 2018
Recorded by Nancy Harrison
link to agenda for this meeting:
https://wiki.OASIS-open.org/dita/PreviousAgendas


Attendance:
Robert Anderson, Deb Bissantz, Carsten Brennecke, Bill Burns, Stan Doherty, Carlos Evia, Richard Hamilton, Nancy Harrison, Alan Hauser, Scott Hudson, Eliot Kimber, Tom Magliery, Chris Nitchie, Keith Schenglie-Roberts, Eric Sirois, Dawn Stevens, Bob Thomas, Don Day, Jim Tivy



Business
========
1. Roll call
Regrets: Maria Essig, Kris Eberlein


2. Approve minutes from previous business meeting:
13 March 2018:
https://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201803/msg00052.html
(Burns, 15 March 2018)
Moved by Tom, 2nded by Nancy, approved by TC


3. Announcements:
New TC members: None


4. Action items
6 September 2016
Kris: Revise subject scheme example topic pulled from errata 01
19 September 2017:
Kris and Robert: Draft response to Radu's blog post and e-mail to dita-comment
13 February 2018
Kris and Bob: Fix style sheets to produce OASIS-requested formatting changes (IN PROGRESS)
- Bob; I've made significant progress, expect to publish compliant stylesheets within a couple of days; just working on HTML output.


5. "LwDITA: An Introduction" committee note
New package: https://www.oasis-open.org/apps/org/workgroup/dita/document.php?document_id=62491&referring_url=%2Fkws
Progress?
Public review requested on 14 February 2018
15-day public review announced on 23 February 2018: https://lists.oasis-open.org/archives/dita/201802/msg00069.html
Public review closed 12 March 2018
- Tom; any updates?
- Carlos; SC met yesterday, we're just waiting for Kris to give us info on what OASIS data we need for the final version of the CN. We won't ask for TC vote today, so you'll have plenty o time to read the final version, maybe for a vote next week.
[expect to vote on the CN next week]


6. DITA 1.3 Errata 02
Wiki page for DITA 1.3 Errata 02
Update:
TC admin provided list of cover page corrections on 06 February 2018
Source changes implemented:
https://lists.oasis-open.org/archives/dita/201802/msg00036.html (Eberlein, 09 Feb 2018)
Style sheet changes needed:
https://lists.oasis-open.org/archives/dita/201802/msg00040.html (Eberlein, 13 Feb 2018)
Progress?
Schedule
https://wiki.oasis-open.org/dita/DITA-1.3-errata-02-schedule
[nothing to cover this week]


7. DITA 2.0 stage three proposals
Vote
None
Initial discussion
None
[nothing to discuss]


8. DITA 2.0 stage two proposals
Vote
None
Continuing discussion
None
Initial discussion

a. Issue # 18: Make audience, platform, product, and otherprops attributes into specializations
https://lists.oasis-open.org/archives/dita/201802/msg00104.html
- Robert; I've updated this after getting reviews from a couple of folks, so I think it's ready for discussion. Originally these @s were the only @s available for filtering/flagging. When we introduced the ability to specialize @s, we couldn't retrofit these. Now, we want to fix these and make these specializations of @props, as they should be; they already work that way. The only difficulty is that users' document type shells will almost all need to be updated to call these as @ domains rather than the way they were. Right now they're universal, but hard-coded; if you want to retain these @s to include these 4 @ domains it should be fairly straightforward.
- Eliot; Is there any reason to retain otherprops?
- Robert; I think so; it's a place to keep metadata short- or long-term; @otherprops seems to be the place for that. That said, the redesign allows anyone who doesn't like @otherprops to now get rid of it.
- Bob; if we decide to get rid of these @s, it would be a really high migration cost.
- Scott; yes, we use it a lot.
- Eliot; why not specialize today?
- Robert; nothing in this proposal will make it easier or harder to specializae @s to do what you're doing.
- Tom; one question; I think it would be helpful to have spec language that distinguishes @otherprops as this special-purpose @, or at least a use case for that. Do we have that language in the spec now? And whether we currently do or not, can we have make sure to have that kind of language in the spec for 2.0?
- Robert; I don't know if we do, but it's a good idea to have it.
- Tom; for anyone who does DITA training, covering usage of @otherprops would need to be covered, and spec language would help a lot.
- Robert; in the original spec, @otherprops was described very generically as the way to get any other filtering done.
- Eliot; but we should also talk about the fact that you can use @props directly, in a way that's much more clear than using @otherprops.
- Robert; but if there are values in there, they're more likely to be generalized @ syntax; using @props directly gets messy if you use the generalized syntax. Also, using @props directly makes folks forget that it's only for specialization. With @props, if you specialize, you end up with the generalized form, and it's easy to get it wrong.
- Eliot; but, e.g. EML editors could make it easy to use that @ and allow for more flexibility...
- Robert; but that doesn't mean they will, for any arbitrary tool.
- Eliot; my problem with @otherprops is that since it's only a sequence of tokens, it's hard to understand what it is; for one condition, it makes sense, but as soon as you add even one more condition, it breaks down.
- Robert; that's where good information architecture really becomes critical... I don't think there's anything we can do to solve that problem.
- Eliot; doing this proposal does simplify things...
- Robert; this problem - using otherprops for toher values - in 1.3 we allowed generalized grouping in @otherpropos, so it fits into specializing, but people read about that syntax and don't get it.
- Tom; is there anything else to say about the proposal?
- Alan; couple of questions; 1) is there any relationship between this proposal and the 2.0 proposal to simplify @ specialization? and 2) is it the case that the simplification proposal only makes base @s specific, but @role would continue to be universal?
- Robert; the proposal you're referring to allows someone to put a specialized @ on only one element, without it having to become a universal @.
- Chris, that's because @props cascade, and others don't.
- Alan; so this proposal would still be implemented using the current @ specialization mechanism; where each @ is a domain?
- Robert; that's correct.
- Tom; what's next for this proposal?
- Robert; if there are no more comments, it gets queued up for vote next week.
***ActionItem; Robert will check the spec to see if language on the purpose and appropriate usage of @otherprops is there, and include the requirement for that language in the stage 3 proposal.
[proposal will get a vote next week]


b. Issue # 106: Allow steps to nest
https://lists.oasis-open.org/archives/dita/201803/msg00054.html
- Robert; I went to my user community at IBM for suggestions, and people really don't like the steps/substeps model; they want steps to nest. The creation of steps/substeps was to support a best practioe (no more than 2 levels of steps in a topic), but people work around it anyway. Also, semantically, there is no difference at all between steps and substeps, so using that markup removes the ability to reuse content - can't conref a substep into a step and vice versa. It also removes the ability to use an 'unordered' substep, since we never defined one. The fix is to remove substeps and allow steps to nest. For folks who really don't want more than 2 levels, we'll need a mechanism to warn about it if they get past 2 levels, but everyone else will be happier. The change will require migration, but it's a fairly simple change that will remove a persistent minor annoyance. - Tom; questions?
- Stan; from your user community, Robert, have you heard the desire to have nested steps in addition to retaining substeps, or the request for nesting?
- Robert; I'm not sure; the requests I hear are 'I want to nest steps.' I think our model is broken now; if we allow nesting and also allow substeps, it would be both weird and broken.
- Robert; if you have a situation where you want substeps to look different from steps, you can still do it, you might just need a bit of migration.
- Tom; it might be a little more work than that, but it's still a valid thing to reduce complexity.
- Robert; the migration costs are noted in the proposal under 'costs'; tools that handle substeps would have to handle nested steps.
- Eliot; what about nested sections?
- Robert; nope, not happening.
- Eliot; good.
- Tom; any questions?
[none]
- Tom; has this been reviewed?
- Robert; yes.
[proposal will get a vote next week]


9. DITA 2.0 stage one proposals
Initial discussion
User-defined topicref format mappers
https://lists.oasis-open.org/archives/dita/201803/msg00030.html (Nitchie, 7 March 2018)
[this discussion includes material from the email conversation referenced in agenda item #10 below.]
- Chris; this fell out of talks on the 'include' proposal. It seemed that you probabaly could achieve translusion of non-DITA content as DITA using conkeyref, if you referenced a process that could transform the content, So I want a way, eithin a map, that you could specify that content was not in DITA and specify a process to represent it the same as surrounding DITA content. This proposal doesn't actually define the transform to be used when moving something into native DITA, but gives map owners a place to say 'magic goes here' and 'we have specific expectations of results'. There's no way to manage the specifics of processing, but that's the case today, it's just implicit, so there's no way for me to know about that. This way, certain aspects are made explicit.
- Eliot; I'm sympathetic to the intent, and don't disagree with design approach, But I think it comes down to; do you see the data as being the primary thing that needs to be as clean as possible, or is the process more important? Both perspectives are important; I typically think 'purity of data is the highest principle.' My concern is that this sort of approach encourages misuse; e.g. I will make it look as if it's a specific transform, rather than a using a format @, as indirection. I'd suggest there's not a big difference between this and my proposal to use magic URLs, if we define specific parameters in keydef that are targets. In Chris's proposal, it's a little more obvious, but there's no way to push out to a separate file a 'magic' URL with some parameters.
- Chris; I'm not adverse to your proposal; in that, the topicref than becomes the pointer to the process, but the href becomes overloaded; it's no longer simply a reference to what's being referenced.
- Eliot; I disagree; a URI is a pointer to a resource.
- Chris; but now you have to teach all your processors how to process all of the info in the href.
- Eliot; that's the job of your URI processor; whatever is in there. resource resolver is the extension point.
- Chris; but other systems will have to be configured with same URI resolution module; I'll have to configure a CMS to correctly process the resolution mechanism.
- Eliot; but there's always a customization needed for that kind of resolution.
- Chris; but in my design, URLs remain ordinary.
- Eliot; if you're referencing a CSV filem, that presumes that CSV file exists; in my view, where I'm usually querying a DB, I don't see reference to a CSV file as being a useful use case.
- Chris; but e.g. for HDITA and MDITA, if you have a processor that's just 1.3 compliant; that won't work. How do you pull that in?
- Robert; as i'm interpreting this, CSV just one of hundreds of formats; it sounds like your approaches are 2 complementary approaches to solving the same problems. Eliot's is the George Bina method with parameterization, it sounds like a different use case from Chris's, which is something more simple, when you just want to reference a file and have some idea of what to do with it.
- Tom; I want to sum this up; what value does this proposal bring to DITA spec? What is currently lacking in the spec that this will benefit? And who benefits? architects? tool vendors?
- Chris; the benefit is to the DITA community at large to enable them to use non-DITA content in their content; it allows map authors to reuse content.
- Eliot; rather than making it possible to use things, it's standardizing a method for stating that it needs to be done. It makes it abvious what the author's intent is, and lets them state that. It can't make it happen, but it just makes author's intent more obvious.
- Tom; we're going to end here; we need to continue this next week
[to be continued next week]


10. New item: Conref Vs. Transclusion and Using Non-DITA Data As DITA
https://lists.oasis-open.org/archives/dita/201803/msg00025.html (Kimber, 06 March 2018)
https://lists.oasis-open.org/archives/dita/201803/msg00028.html (Nitchie, 07 March 2018)
https://lists.oasis-open.org/archives/dita/201803/msg00028.html (Anderson, 07 March 2018)
https://lists.oasis-open.org/archives/dita/201803/msg00032.html (Kimber, 07 March 2018)
https://lists.oasis-open.org/archives/dita/201803/msg00033.html (Nitchie, 08 March 2018)
[this material is referenced within discussion of agenda item #9 above]


12 noon ET close

-- Ms. Nancy Harrison
Document Name: DITA TC Meeting Minutes 20 March 2018

No description provided.
Download Latest Revision
Public Download Link

Submitter: Ms. Nancy Harrison
Group: OASIS Darwin Information Typing Architecture (DITA) TC
Folder: Meeting Notes
Date submitted: 2018-03-21 01:33:18



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