-----Original Message-----
From: Lofton Henderson [mailto:lofton@rockynet.com]
Sent: Tuesday, January 27, 2009 10:32 AM
To: cgmo-webcgm@lists.oasis-open.org
Cc: David Cruikshank
Subject: [cgmo-webcgm] [POLL] Re: Don's question
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 true for 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 and gap 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