Question: XCF coding the same as DOM?

[Lofton Henderson <lofton@rockynet.com>]

WebCGM TC,

While doing some editing, I came up with a couple questions.  The
1st is probably trivial; maybe also the 2nd.  Does anyone disagree
with the two RECOMMENDATIONs?  (Dave, can we reaffirm these in
telecon?)

1st QUESTION:  Is it our intention that parameter coding in the XCF
should be the same as in DOM calls?

Explanation:  Example 4.1 in XCF (CD text) has:
<grobject apsid="id_2"
region="1,200,0,300,100"/>

This is the same as shown in the DOM table 5.7.6 (CD text). 
There, we subsequently decided:
-- stuff in 'viewcontext' would be single string with individual numbers
wsp-separated;
-- stuff in 'region' is delimited string (sec 5.5), with wsp
separation;

RECOMMENDATION:  YES, code the stuff in XCF attributes the same as
in DOM calls.

2nd QUESTION:  Should we keep that consistency even for
'linkuri'?

Explanation:  For linkuri, the DOM call would be:

obj1.setAppStructureAttr(
"'http://www.w3.org'
'W3C home page' ''  
'http://www.cgmopen.org'
'' '_blank'")

The current XCF definition would be:
<grobject apsid="obj1" ...  >
   <linkuri uri='http://www.w3.org' desc='W3C home page'>
   <linkuri uri='http://www.cgmopen.org'
behavior='_blank'>
</grobject>

XCF could in fact be done consistently with the DOM call:
<grobject apsid="obj1"
linkuri="'http://www.w3.org'
'W3C home page' '' 
'http://www.cgmopen.org'
'' '_blank'"  />

Advantages for "consistent":  DOM implementations
will already understand the delimited string with 3n substrings, so
loadAndApply can use same utilities as DOM API to parse the
parameter.  JS applications would be more straightforward (if doing
get/set consecutively).

Disadvantages:  Less user friendly -- the delimited-string form is
tedious to hand code.  (Other disadvantages?)

RECOMMENDATION:  NO.  (Leave as is, with the user-friendly form
for this exception.)

Regards,
-Lofton.