[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: Values for @status on <draft-comment>
|
I guess my only argument for not relaxing @status is that it’s been like that forever and has a very specific meaning, however unuseful it ends up being in practice. Applications that do do something with
@status (and here I’m thinking of tools like DeltaXML that are able to capture differences using DITA markup, so using @status values) would only be implemented against the current values and wouldn’t expect new values. If the desire is to have an attribute specific to <draft-comment> for expressing workflow status, then clearly @disposition does that. If the desire is to have a global attribute that can capture review workflow status for any element, then it seems like a new attribute with exactly that semantic would be most appropriate, i.e., @workflow-status
or something. Thinking back, I think I’ve tried to use @status to capture (and then report) add/remove/delete status and decided it was not the best approach, given tools that can do precise XML-aware differencing, including
both OxygenXML and DeltaXML, as well as normal version control systems like git. Cheers, E. _____________________________________________ Eliot Kimber Sr Staff Content Engineer O: 512 554 9368 M: 512 554 9368 LinkedIn | Twitter | YouTube | Facebook From:
kris eberleinconsulting.com <kris@eberleinconsulting.com> [External Email] 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]