[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: re[2]: [cgmo-webcgm] [POLL] Re: Don's question
Agreed. I was assuming that, but neglected to say it -- same treatment for
those other 3 similar things (gapWidth, directionVectors, lineTypeIndex) in
the ACI defaults stuff.
-Lofton.
At 11:56 AM 1/28/2009 -0600, Don wrote:
>Lofton,
>
>Since the consensus and proposed resolution is-
>"make dashLength an XML attribute coded as list-of-numbers".
>
>I think we should also apply this change to gapWidth, directionVectors,
>lineTypeIndex. That is, make these XML attributes of hatchStyleDef.
>A hatchStyleDef would for example be coded like this-
>
><hatchStyleDef hatchIndex="1" styleInd="parallel" cycleLength="100"
> numberOfLines="4" directionVectors="0 1 1 0" gapWidth="2 1 4 1"
> lineTypeIndex="1 2 3 4"
></hatchStyleDef>
>
>
>Don
>
>
> > 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
>
>
> > ---------------------------------------------------------------------
> > 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
>
>---------------------------------------------------------------------
>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]