[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Values for @status on <draft-comment>
Yes. @status is a general metadata attribute, but why would we want to limit it to the current set of tokens? I suspect the tokens were what IBMIDDOC supported … If we changed @status to NMTOKEN, individual implementations could define values for @status in a subject scheme map and bind them to applicable attribute/element pairs. Best, Kris Kristen James Eberlein Skype: kriseberlein; voice: +1 (919) 622-1501 From: dita@lists.oasis-open.org <dita@lists.oasis-open.org>
On Behalf Of Eliot Kimber Actually, reviewing the @status attribute in the spec, I think it needs to remain as it is as it’s a general metadata attribute. The @disposition attribute, as Zoe points out, is what we are looking for and it already allows any value. Here’s the definition of @disposition: Specifies the status of the draft comment. I’m not sure I’ve ever thought about this attribute before (I haven’t used draft comments that much). But in the context of our Content Fusion reviews where we are using <draft-comment> it looks like @disposition is the place to record
the disposition status of the comment. I would amend the current definition of @disposition to be something like: Specifies the disposition of the draft comment in the context of some review process, i.e., “open”, “pending”, “resolved”, etc. Cheers, E. _____________________________________________ Eliot Kimber Sr Staff Content Engineer O: 512 554 9368 M: 512 554 9368 LinkedIn | Twitter | YouTube | Facebook From:
Zoe Lawson <zoelawson17@hotmail.com> [External Email] How does @disposition interact with @status? Why are there both? (There's probably a really good reason, I'm just ignorant.) I am fine with making @status unrestricted. Zoë Lawson (she/her) From:
dita@lists.oasis-open.org <dita@lists.oasis-open.org> on behalf of Eliot Kimber <eliot.kimber@servicenow.com> I can’t see a reason to not allow unrestricted values. The declaration should be NMTOKEN if the intent is to allow any single keyword value. I can definitely see wanting values like “resolved”, “under-review”, “rejected”, etc.—the usual review workflow states and status values. Cheers, E. _____________________________________________ Eliot Kimber Sr Staff Content Engineer O: 512 554 9368 M: 512 554 9368 LinkedIn | Twitter | YouTube | Facebook From:
dita@lists.oasis-open.org <dita@lists.oasis-open.org> on behalf of kris eberleinconsulting.com <kris@eberleinconsulting.com> [External Email] The values for @status on <draft-comment> are currently limited to the following:
This seems unnecessarily limiting. Is there a reason that we should not change to PCDATA? Also, is this limited set of tokens what is permitted for @status on other elements? How many of you all are aware of DITA implementations that have used @status? Best, Kris Kristen James Eberlein Skype: kriseberlein; voice: +1 (919) 622-1501 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]