[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: re: [cgmo-webcgm] [POLL] Re: Don's question
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]