[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re[2]: [cgmo-webcgm] Question: XCF coding the same as DOM?
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]