[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: re: [cgmo-webcgm] [POLL] Re: Don's question
Okay, everyone who has expressed a preference has opted for #2. I will list this as the proposed resolution, and we will confirm in a telecon (formally, it needs to be confirmed in the WG now). -Lofton. At 05:10 PM 1/27/2009 -0600, Don wrote: >Lofton, > >I prefer #2. > >It's easier to code (less verbose) for users and also to decode in the viewer. > >Don > > > All -- > > > This is a straw POLL -- please respond, everyone. > > > We have sorted out and all agree that dashLength is a sub-element in > > current ACI specs. In discussion with Dave, we have discovered that a > > slight deviation crept into the ACI chapter between 1st CD and 2nd CD > > (according to Dave). He had the idea that dashLength would be a > > repeatable element, with each occurrence carrying one integer. So a > > pattern of 3 solid segments and 3 gap segments would require 6 > elements. > > > Hence the DTD content model says dashLength+. > > > Somehow, the cleanup and integration of the chapter came out with the > > content of dashLength being a blank-separated list of integers > > (WebCGMString list-of-number subtype). But it still retained "+", which > > obviously leads to a redundant formulation. > > > Dave proposes that we should choose between two possibilities: > > > 1.) as originally designed: one integer per dashLength element, and > > dashLength+ in the content model. > > or > > 2.) as a WebCGMString-list-of-number subtype -- allowing a list of > > blank-separated integers -- within dashLength as an XML *attribute*. > > (Dave says it may as well be an attribute instead of a one-occurrence > > element in this case.) > > > ========== > > POLL: Do you prefer #1 (DC's original design), or #2 (like LCWD text > > except XML attribute instead of XML element)? > > ========== > > > Note A: Dave points out one attribute of #1 is that it doesn't require > > much parsing. On the other hand, #2 requires some parsing, but that > > list-of-number subtype was used in WebCGM 2.0, so implementations should > > already have that capability. > > > Note B: The same logic and POLL choices #1 and #2 apply to gapWidth and > > lineTypeIndex, each of which must handle a variable-length list of > > integers. > > > Note C: directionVectors is similar in some ways. In CGM:1999 it is 4 > > numbers ("4SS"). Here, the DTD says that the directionVectors element > > contains 4 sub-elements: vectorX, vectorY, vectorX, vectorY. Each > of the > > 4 vectorX/vectorY elements contains one #PCDATA (i.e., one number). The > > text preceding the DTD snippet seems contradictory, "The 4 numbers of > > directionVectors are encoded in the format of the WebCGMString > > List-of-number subtype." (Well, I guess it could be list-of-number, with > > list length "1". So if you like #2, then directionVectors could > become an > > XML attribute. If you like #1, it would continue to be an element that > > contains 4 sub-elements, each of which carries one number. > > > Threads: > > http://lists.oasis-open.org/archives/cgmo-webcgm/200901/msg00056.html > > http://lists.oasis-open.org/archives/cgmo-webcgm/200901/msg00069.html > > > Regards, > > -Lofton. > > > At 02:07 PM 1/26/2009 -0800, David Cruikshank wrote: > > I guess just put it to a poll. My only reason for repeating the element > > was to make it easier to parse, but if everyone already does it, it > > doesn't make any difference. > > > Most of the arguments about element vs attributes center around > > presentation applications and not database applications which is what > this > > really is like. > > > thx..Dave > > > On Mon, Jan 26, 2009 at 1:44 PM, Lofton Henderson <lofton@rockynet.com> > > wrote: > > I vaguely remember some head scratching and trying to figure out what > > "repeatable string" meant, and it was probably then that the list idea > > came along. > > > > Okay, where do we go with it now? I don't have a strong opinion. Shall > > we ask the members? [...] Just call it a POLL and vote for one or the > > other of your two options? > > > Btw, this also affects the other two similar items, and I guess the > > directionVectors also (may as well be attribute). > > > > -Lofton. > > > > > At 12:50 PM 1/26/2009 -0800, David Cruikshank wrote: > > Yep, that wording happened between the `1st and 2nd CD. It actually > > happened after the f2f. when I was "winding down".. the wording in the > > 1st CD the dash length was defined as and "element of the ACI is a > > repeatable string that specifies a the length of each dash and gap in the > > defined line pattern". It was not originally intended to be a list. > > > I guess it doesn't really make any difference, but if it is a list, it > > might as well be an attribute. The only reason for making it an element > > is the fact that it is repeatable and captures each value in the > sequence. > > The same is truefor all of the similar elements. > > > I think the choices are 1) keep it as a list and make it an attriubte, or > > 2) leave it as an element and return the the original intent. > > > thx...Dave > > > On Mon, Jan 26, 2009 at 9:42 AM, Lofton Henderson <lofton@rockynet.com> > > wrote: > > Dave, > > > Do you want me to archive the below message also? Or wait till you > have a > > look at Ch.9 > > > Have a look not only at dashLength, but also gapWidth and lineTypeIndex, > > which are also variable-length lists of numbers. (For which I we might > > have invented the @@List-of-number@@ subtype -- can't remember if it > > already existed or not.) > > > directionVectors is also a list-of-number, but always 4 numbers. > > > [1] > > > http://www.w3.org/Graphics/WebCGM/drafts/current-editor-21/WebCGM21-Config > > .html#ACI-dashlen > > > I agree that we could do away with "+" if we want to keep the > > list-of-number -- that is a datatype that exists in 2.0 (I just checked), > > so everyone has implemented it. > > > Or we could keep the "+" and say what happens with multiple occurrences > > ("last wins" or "accumulate"). But that doesn't really add any > > functionality, so I would opt towards simplicity: one way or the other, > > not both. > > > Btw, I'm not sure if this happened in your original draft, or on the > other > > hand whether I introduced it when integrating and making the language > > uniform. > > > > -Lofton. > > > > > At 08:40 AM 1/26/2009 -0800, David Cruikshank wrote: > > Let me go back and read what's in Chap 9. The intent was the each > > occurrence of dashLength contain a single integer and that you would just > > multiple occurrences to define the pattern. > > > I can live with putting the whole string into a single occurrence, but > > then you want to remove the "+" off the model because it no longer makes > > any sense. > > > I'll take a look and formulate a response later today. > > > Dave > > > On Sun, Jan 25, 2009 at 4:24 PM, Lofton Henderson <lofton@rockynet.com> > > wrote: > > Dave, > > > I think you missed Forrest's later message about this: > > http://lists.oasis-open.org/archives/cgmo-webcgm/200901/msg00057.html > > > He pointed this out: dashLength is a sub-element of lineEdgeTypeDef. > > I.e., it is an element in the content model of lineEdgeTypeDef. Forrest > > is correct, according to the DTDs. Therefore, dashLength should precede > > the close tag of lineEdgeTypeDef. > > > That aside, I agree that it is a matter of taste whether to make things > > attributes or elements. I'm not one (XML expert), but I understand that > > XML experts fight religious wars about element-or-attribute. Myself, I'm > > content to live with your choice (or any other). > > > However, there is another issue to clarify > > > It [2] says: "The dashLength element is a string, in the encoding of the > > ACI file, that contains a list of non-negative integers in the format of > > the WebCGMString List-of-number subtype. The integers specify the lengths > > of each dash andgap in the defined line pattern in abstract units, that > > are then normalized as a whole pattern to the repeatLength attribute of > > lineEdgeTypeDef. The first integer corresponds to solid, the second to > > gap, the third to solid, etc." > > > That seems to clearly say that you can put the whole sequence into the > > CDATA content of one dashLength element. > > > So this raises a new issue for clarification: since the content model > > says dashLength+, then what happens with 2 (or 3, or more) occurrences of > > dashLength? > > > 1.) last one wins; > > 2.) or, the integer list accumulates. > > > Your example (below) would suggest #2. > > > Thoughts? > > > (I'll redirect your answer if you like.) > > > -Lofton. > > > [1] http://lists.oasis-open.org/archives/cgmo-webcgm/ > > [2] > > > http://www.w3.org/Graphics/WebCGM/drafts/current-editor-21/WebCGM21-Config > > .html#ACI-ledtdef > > > > > > > > At 05:12 PM 1/25/2009 -0700, David Cruikshank wrote: > > [...redirected to TC list by Lofton...] > > > I can't respond to the TC email list, so I'm sending my response this > way. > > > Don asked about the content model for the aci: > > > > > > > > > > > > I'm directing this question to you since you created the ACI DTD and > > perhaps could shed some light on this and at the same time confirm my XML > > coding. dashLength is defined as an Element rather than as an > Attribute of > > lineEdgeTypeDef, thus an example the the XML encoding I believe would be- > > <webcgmConfig <lineEdgeTypeDef lineIndex="1" repeatLength="100" > > </lineEdgeTypeDef> <dashLength>"10 2 5 2"</dashLength> > </webcgmConfig> > > However it seems more natural for dashLength to be an Attribute > and coded > > like this: <webcgmConfig <lineEdgeTypeDef lineIndex="1" > > repeatLength="100" dashLength="10 2 5 2" </lineEdgeTypeDef> > > </webcgmConfig> This also applies to the directionVectors and gapWidth > > Elements assocaited with the hatchStyleDef. My response: > > > When things are repeatable, I've tended to make them repeating > elements as > > opposed to attributes. I think the correct encoding for your example is: > > > > > <webcgmConfig > > <lineEdgeTypeDef lineIndex="1" repeatLength="100" > > </lineEdgeTypeDef> > > <dashLength>10</dashLength> > > <dashLength>2</dashLength> > > <dashLength>5</dashLength> > > <dashLength>2</dashLength> > > </webcgmConfig> > > > Remember dashLength is specified as "dashLength+". That way no > parsing is > > required to figure out the values. > > > If people want parse, it's ok but this was an attempt to simplify the > > work. > > > > > Dave > >--------------------------------------------------------------------- >To unsubscribe from this mail list, you must leave the OASIS TC that >generates this mail. Follow this link to all your TCs in OASIS at: >https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]