dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Groups - DITA TC Meeting Minutes 3 November 2020 uploaded
- From: Nancy Harrison<nharrison@infobridge-solutions.com>
- To: <dita@lists.oasis-open.org>
- Date: Sat, 7 Nov 2020 07:29:11 +0000 (UTC)
Submitter's message
ActionItems:
1. Gershon, Deb, Stan, Scott, & Eric will post resource-id examples to list, so Eliot can havs more info.
=================================================
Minutes of the OASIS DITA TC
Tuesday, 3 November 2020
Recorded by Hancy Harrison
link to agenda for this meeting:
https://wiki.OASIS-open.org/dita/PreviousAgendas
Attendance:
Robert Anderson, Deb Bissantz, Carsten Brennecke, Stan Doherty, Kris Eberlein, Nancy Harrison, Scott Hudson, Gershon Joseph, Eliot Kimber, Zoe Lawson, Chris Nitchie, Eric Sirois, Dawn Stevens, Frank Wegmann, Jim Tivy
Business
========
1. Roll call
Regrets: Carlos Evia, Keith Schengili-Roberts
2. Approve minutes from previous business meeting:
27 October 2020
https://lists.oasis-open.org/archives/dita/202010/msg00066.html (Harrison, 31 October 2020)
moved by Kris, 2nd by Dawn, approved by TC
3. Announcements: none
4. Action items
[updates only, see agenda for complete list]
27 October 2020
Kris: Schedule meeting with Chris Nitchie and Robert Anderson about the intersection of proposals #16 and #345 COMPLETED
Kris: Add discussion of issue #15 Loosen attribute specialization rules to agenda for 03 November 2020 COMPLETED
5. Check-in: How are people doing in this difficult time? How is your state/country doing?
[no official business discussed]
6. Review of DITA 2.0 proposal deadlines
https://wiki.oasis-open.org/dita/DeadlinesDITA2.0
[updates only; see above link for complate list]
Stage two
(Kimber) Deprecate or remove copy-to attribute (https://github.com/oasis-tcs/dita/issues/33)
- see agenda item #7 for discussion
(Eberlein) New element for key text (https://github.com/oasis-tcs/dita/issues/345)
- Kris; when can i get comments from Chris and frank?
[end of the week]
Stage three
(Nitchie) Loosen attribute specialization rules (https://github.com/oasis-tcs/dita/issues/15)
- see agenda item #8 for early feedback
7. DITA 2.0 stage two proposals
Initial discussion
Issue #33 Remove copy-to
https://lists.oasis-open.org/archives/dita/202010/msg00058.html (Kimber, 26 October 2020)
https://lists.oasis-open.org/archives/dita/202010/msg00062.html (Jim Tivy, 29 October 2020)
https://lists.oasis-open.org/archives/dita/202010/msg00063.html (Kimber, 30 October 2020)
https://lists.oasis-open.org/archives/dita/202011/msg00006.html (Jim Tivy, 02 November 2020)
- Eliot; idea is to remove copy-to and use resource-id in its place, for its intended use. We created copy-to as a hint for anchors; in past, where you'd use copy-to, now you can use resource-id instead. And if you use keys, you can use those. It was solving a problem that wasn't really solvable, except thru something like reosurce-id, which was; how to get to specific anchors. It was an attempt to do that, but it was created in context of DITA-OT, so it wasn't flexible. This is our chance to get rid of it, since resource-id is the obvious flexible way for authors to indicate the anchors they want; text and examples.
- Robert; I wondered if was unclear whether resource-id is meant to be a mandated way to replace it, or just one way they could...
- Eliot; processors should support resource-id as a mechanism by which authors can control and define anchors. If you have resource-id in content, we should expect that processors will handle it.
- Robert; a lot of folks use this; if we're replacing it, it has to be with something that is mandated; we have to have a clear replacement.
- Eliot; I agree with that; I just didn't say it strongly enough. I don't disagree with making support for resource-id mandatory.
- Kris; we need to tweak the proposal to say it's removing ocpy-to, setting resource-id as replacement, and requiring processors to support resource-id.
- Kris; Robert; does that address your comments?
- Robert; if there's an @ value that indicates what role resource-id has; it can have many, and we want to be clear.
- Eliot; I was thinking about that; we already have mapid, so we can bind resource-id to a specific delivery context. till now, resource-id has been preented in a context of online help; is its use limited to that?
- Kris; resource-id is used pretty heavily; it's often used for 'here's the value in our help system mapping.'
- Eliot; so the question is; if you already have content with resource-id in it, and you have your resource-id that targets the help system; if you also use it for pdf, do you have to have a new appid to specify that? I didn't want to overspecify, but rule would be that if you have a resource-id with no appid, then you're defining for all deliverables, otherwise yuo need an appid.
- Chris; I've set resource-id="externalanchor", we mandate a target
- Robert; then you'd need 2 different resource-id's, wouldn't you?
- Eliot; isn't appid a token list?
- Robert; no it's CDATA.
- Eliot, so you can put in anything you'd like, so it could be a token list. My other concern is that it sets up a 'simon says' behavior; if you don't set up keyword, you don't get the behavior you expected.
- Robert; you can use it for anything today; we don't want to stomp on that
- Eliot; is this a case that needs to be signaled thru some special value?
- Robert; if not, we can't use it instead of copy-to
- Kris; we've said we would like consistency on how processors implement this; we can't do that without specifying a token to guide processors.
- Scott; would adding deliverytarget help?
- Robert; you could have this for different things, and you could use deliverytarget to get different outputs.
- Eliot; I was thinking of using appid the way you just described deliverytarget.
- Robert; this is why we need specific examples; I thought appid was the actual anchor.
- Eliot; appname is the id of the app to which that kind of anchor applies.
- Robert; that leaves everything up to apps to define tokens and events. I don't think we can just specify "put in your app and processors have to implement it" - that would be requiring magic.
- Kris; who has customers or an implementation that is using resource-id today?
- Gershon; all my clients use it.
- Deb; I have clients using it.
- Stan; we do also.
- Scott; we do also.
- Kris; can all of you provide the TC with examples?
- Eric; we use it as well.
- Eliot; that's what we do also; so how do we signal to a given processor?
- Robert; everyone's using it; we need to make it consistent.
- Kris; would it help for the folks using it to publish to the list the way it's used for them?
- Eliot; I was going from the assumption it wsn't used much, and only for online help, but that's clearly not correct...
***ActionItem: Gershon, Deb, Stan, Scott, & Eric will post resource-id examples to list, so Eliot can havs more info.
- Kris; let's hold further discussion till we see the examples.
- Eliot; Robert and I agree this should be mandatory for processors, does everyone agree with that?
- Kris; does everyone agree to make certain useage of resource-id mandatory, so we have a replacement for copy-to?
[general agreement]
- Gershon; probably all our examples are processed the same way, since we're using the DITA-OT. Since this is for 2.0, I don't mind us mandating it. most vendors are using DITA-OT as well.
- Kris; but that doesn't matter from point of view of the spec.
- Gershon; but since it's a major release, we can mandate stuff. It will improve both usage and the spec.
- Robert; I don't think DITA-OT is relevant here; the question is, should the spec say it's mandated for processors?
- Gershon; but the impact on vendor community will be small.
- Kris; does anyone have concerns about moving forward with specifying a usage of resource-id as a replacement of copy-to, and inserting MUST statements about what processors must support?
[none]
8. DITA 2.0 stage three proposals
Early feedback
Loosen attribute specialization rules (https://github.com/oasis-tcs/dita/issues/15)
Simplifying specialization rules - the state of the discourse
https://lists.oasis-open.org/archives/dita/202011/msg00001.html (Nitchie, 01 November 2020)
https://lists.oasis-open.org/archives/dita/202011/msg00002.html (Graydon Saunders, 02 November 2020)
https://lists.oasis-open.org/archives/dita/202011/msg00003.html (Kimber, 02 November 2020)
- Chris; this is a proposal that's been languishing; it has a lot of conceptual complexity. Basically, it requires the ability to creat a constraint module that instead of constraining elements, adds an @ in only a specific element. We have constraints already, and this is essentially the same thing, but different in concept. How do we name and describe these things in the spec? I started with calling them a 'mixin', but ended up using a ton of the language from our content about constraints, literally copy/pasting it in. So for instance, if you want two constraints on the same element, you need a and b and a+b, when you have both a constraint and a mixin on the same element, you have to merge them into the same thing. So I came to the conclusion that these are two aspects of the same thing, but I don't have a name for that thing. So that's where we are. what are constraints and 'mixins' subcategories of? Robert and Kris didn't like touching constraints the way this is doing. The engineering is clear, but the wordsmithing isn't. So how do we talk about these things? What's the conceptual model? How do we introduce them without messing too much with constraints?
- Eliot; my suggestion was that this is all configuration, so we can call it configuration modules, which can consist of constraints and mixins; we're basically integrating constraints at the content model level rather than at the shell level.
- Kris; I'm more comfortable with that than with content model specialization, because we're not talking about specialization when we talk about this. And I don't like 'mixins' either.
- Robert; I've come around to thinking that we don't even need a term for it; I agree with Eliot's idea on configuration. you could do it today, but it's not functionally possible, because it's so hard. We could get there, but it's like creating a domain and then constraining it to a ridiculous degree.
- Eliot; I do this thing today just the way Chris describes, it's just not allowed; this proposal essentially removes the spec language that mandates how grammar files have to be constructed.
- Robert; so if we just gave examples, and took out the language restricting it, then it becomes legal.
- Eliot; if you allow an element in a content model, has to be a valid specialization.
- Robert; right now, we say if you do a domain specialization of a p, you have to set up the shell so it's allowed anywhere a p is allowed. We could do a whole bunch of constraints. If domain replacement becomes legal, the implentation would look a lot like a constraint. and that fits under 'configuration' if we put domain and constraint together.
- Chris; so is a constraint a kind of configuration? It has to go in a separate file, can't go in the same file as a domain. Things have to be defined before it can be processed.
- Robert; I'm thinking in terms of DTDs, Yes, if we're thinking in terms of concepts, not the individual case, and if we don't worry about how many modules, I'm not sure we have to give it a new name.
- Kris; I think we might need a new name.
- Robert; I would do this by implementent a domain and a constraint; would skip the line that says; "this goes everywhere that 'base element' goes".
- Kris; then what Chris describes as a 'mixin', we just call a constraint. it's the same, so we don't need a name for the union of the two.
- Robert; this appeals to me, one of the big stumbling blocks is coming up with a name, it's just using existing concepts in a slightly new way.
- Kris; then to clarify, we're changing the way that domains have to function. the elements or @s you don't want to be globally available should be implemented in a constraint.
- Chris; the problem is using 'constraint' for something that's added...
- Robert; we don;t define this as a constraint; it fits under 'configuration' you do it using a domain and a constraint. A domain extension that would ordinarily go everywhere, plus a constraint. Removng the mandate of having that one ilne in your shell makes it much easier. we shouldn't care about that line in the shell.
- Eliot; in the context of 1.3, we allow a domain to not be integrated in a shell, and we call that a constraint. but we don't let you use that domain where you want it.
- Chris; there's a reason not to do this, too...
- Kris; Chris, do you want to think about it and we'll bring it back next week?
- Chris; yes, but this make a constraint a kind of configuarion.
[to be continued next week.
12 noon ET close
-- Ms. Nancy Harrison
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]