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

[Lofton Henderson <lofton@rockynet.com>]

Okay, then...

Proposed resolution.  We will code parameters (XML attributes) in XCF -- 
e.g., for 'region' -- identically to how they are coded in DOM, *except* 
for linkuri.  Linkuri will remain as it is in section 4.7 of (1st) CD text.

Objections?

-Lofton.

At 09:17 AM 5/26/2005 -0400, Benoit Bezaire wrote:
>Hi,
>
>Here's my opinion on those two questions:
>
>From: Lofton Henderson   [mailto:lofton@rockynet.com]
>   1st QUESTION:  Is it our intention that parameter coding in the XCF
>   should be the same as in DOM calls?
>
>   RECOMMENDATION:  YES, code the stuff in XCF attributes the same as
>   in DOM calls.
>
>Yes. I don't see any reason why we should request implementation to
>implement two sets of parsers.
>
>
>From: Lofton Henderson   [mailto:lofton@rockynet.com]
>   2nd   QUESTION:  Should we keep that consistency even for 'linkuri'?
>
>   RECOMMENDATION:  NO.  (Leave as is, with the user-friendly form for
>   this exception.)
>
>I agree with no. I don't really see what the benefit would be to the
>user. I think the XCF syntax is easy enough to understand as is. It
>doesn't really complicate the implementation of the
>applyCompanionFile() method since you already have to look for child
>elements (for namespace metadata elements).
>
>--
>  Benoit   mailto:benoit@itedo.com
>
>
>Monday, May 23, 2005, 4:09:41 PM, Dieter wrote:
>
>DW> Hi Lofton,
>
>DW> -----Original Message-----
>DW> From: Lofton Henderson   [mailto:lofton@rockynet.com]
>DW> Sent: Monday, May 23, 2005 8:40   PM
>DW> To: cgmo-webcgm@lists.oasis-open.org
>DW> Subject: [cgmo-webcgm] Question: XCF coding the same as DOM?
>
>
>
>DW> WebCGM TC,
>
>DW> While doing some editing, I came up with a couple
>DW> questions.  The 1st is probably trivial; maybe also the 2nd.  Does
>DW> anyone disagree with the two RECOMMENDATIONs?  (Dave, can we
>DW> reaffirm   these in telecon?)
>
>DW> 1st QUESTION:  Is it our intention that   parameter coding in
>DW> the XCF should be the same as in DOM   calls?
>
>DW> Explanation:  Example 4.1 in XCF (CD text) has:
>DW> <grobject apsid="id_2"   region="1,200,0,300,100"/>
>
>DW> This is the same as shown in the   DOM table 5.7.6 (CD
>DW> text).  There, we subsequently decided:
>DW> -- stuff   in 'viewcontext' would be single string with
>DW> individual numbers   wsp-separated;
>DW> -- stuff in 'region' is delimited string (sec 5.5), with wsp  separation;
>
>DW> RECOMMENDATION:  YES, code the stuff in XCF attributes   the same as 
>in DOM calls.
>DW> [DW] Agreed.
>
>DW> 2nd   QUESTION:  Should we keep that consistency even for   'linkuri'?
>
>DW> Explanation:  For linkuri, the DOM call would   be:
>
>DW> obj1.setAppStructureAttr(
>DW> "'http://www.w3.org' 'W3C home page' ''
>DW> 'http://www.cgmopen.org' ''   '_blank'")
>
>DW> The current XCF definition would   be:
>DW> <grobject apsid="obj1" ...  >
>DW>      <linkuri uri='http://www.w3.org' desc='W3C home page'>
>DW>      <linkuri uri='http://www.cgmopen.org'   behavior='_blank'>
>DW> </grobject>
>
>DW> XCF could in fact be   done consistently with the DOM call:
>DW> <grobject   apsid="obj1"
>DW> linkuri="'http://www.w3.org' 'W3C home page' ''
>DW> 'http://www.cgmopen.org' ''   '_blank'"  />
>
>DW> Advantages for "consistent":  DOM   implementations will
>DW> already understand the delimited string with 3n   substrings, so
>DW> loadAndApply can use same utilities as DOM API to parse the
>DW> parameter.  JS applications would be more straightforward (if
>DW> doing   get/set consecutively).
>
>DW> Disadvantages:  Less user friendly -- the   delimited-string
>DW> form is tedious to hand code.  (Other   disadvantages?)
>
>DW> RECOMMENDATION:  NO.  (Leave as is, with the   user-friendly form for 
>this exception.)
>DW> [DW] First   thought was no, but then...
>
>DW> This   would eliminate the need for a separate <linkURI>
>DW> element, which might   actually simplify our interfaces
>
>DW> and   DOM calls quite a bit, especially when enumerating
>DW> attributes. However, this   would only make sense, if
>DW> we at the same time would amend the linkURI   APS Attr to
>DW> hold the same string, i.e. merge all linkURIs into
>DW> one APS   attribute. This is something that should have been
>DW> done at the very   beginning...
>DW> I am not sure whether we want to go this far   though.
>
>DW>
>
>DW> Cheers,
>
>DW> Dieter
>
>DW> Regards,
>DW> -Lofton.