OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cgmo-webcgm message

[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]