RE: [cgmo-webcgm] Question: XCF coding the same as DOM?

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.
[DW] Agreed.

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.)
[DW] First thought was no, but then...

cgmo-webcgm message