[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [sarif] Provisional draft includes all changes
Actually we can do better: let’s say that the property is required for tools that process text files (no change from current spec), but forbidden for tools that don’t process text files. This is the minimal change from the current spec, and points right at the problem – this property doesn’t make sense for non-text-processing files. From: Larry Golding (Comcast) <larrygolding@comcast.net> With regard to #2 (making columnKind optional) I now agree with Michael. I filed Issue #191 (CSD.1): “run.columnKind is optional”, as follows: The TC approved #178, which defined the required property To fix this problem, we will make the property optional. This approach has the following features: · Tools that emit · Tools that do not emit · We do not specify a default (a very contentious issue which we can sidestep). · We do not have to specify a I will do the following, similar to how I approached Issue #189:
Thanks, Larry From: sarif@lists.oasis-open.org <sarif@lists.oasis-open.org> On Behalf Of Larry Golding (Comcast) I filed Issue #189, “Make result.workItemUris an array.” From: sarif@lists.oasis-open.org <sarif@lists.oasis-open.org> On Behalf Of Larry Golding (Comcast) We agree on #1. I’ll file an issue and make the change in the provisional draft. I’ll put a change-barred version in the “Accepted” folder. I can move it to “Rejected” and revert the change in the unlikely event the TC rejects it in the e-ballot. As for #2: As you say, Jim worried that if we chose the wrong default, a tool that accidentally omitted columnKind would induce unexpected behavior in the consumer (for example, the consumer would interpret columns as UTF-16 code units when the producer meant them to be interpreted as Unicode code points). But if we do what you say, a tool that accidentally omits columnKind will induce unpredictable behavior in the consumer (some consumers might interpret the columns as UTF-16 code units, and others as Unicode code points). To my mind, that’s worse. I still prefer my proposal of keeping columnKind as required (which is what the TC approved), and adding a value "none" that non-text-processing tools can use. Larry From: Michael Fanning <Michael.Fanning@microsoft.com> My suggestion:
Michael From: sarif@lists.oasis-open.org <sarif@lists.oasis-open.org> On Behalf Of Larry Golding (Comcast) Here is the status:
I propose:
I will wait for resolution of those two issues before creating the ZIP. May I ask Michael to help me drive resolution of the two issues (by which I mean, gently nudge people who care about them to weigh in – I’m not good at that), and David and Stefan to adjust our balloting process to accommodate the changes, if we accept them. Thanks, Larry |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]