re[2]: Don's question

[Don <dlarson@cgmlarson.com>]

Lofton,

 >  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.  

I did see Forrest's email but we have 2 different interpretations on this.
Forrest's encoding would be this:

<webcgmConfig 
   <lineEdgeTypeDef lineIndex="1" repeatLength="100" 
       <dashLength>"10 2 5 2"</dashLength>
   </lineEdgeTypeDef> 
</webcgmConfig>


Whereas Dave says this is what he meant:

<webcgmConfig
   <lineEdgeTypeDef lineIndex="1" repeatLength="100"
   </lineEdgeTypeDef>
   <dashLength>10</dashLength>
   <dashLength>2</dashLength>
   <dashLength>5</dashLength>
   <dashLength>2</dashLength>
</webcgmConfig>


I think it's logical for dashLength to be sub element and a single 
string as Forrest has it but I don't think that is what the spec
says now.

Don

 >  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