[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cgmo-webcgm] New draft snapshot
Here are a few little things I noticed while looking at the new draft (great progress!!!) ... 1.1.1, 2nd pgph, editorial nit: "using namespace attributes and elements in the XML companion file...". Is "namespace attributes" the right terminology? Does namespace attribute refer simply to "xmlns"? I'm uncertain, just asking. (We mean attributes and elements in some distinct application namespace, or "namespaced attributes", or ...) 1.1.1, "wiring" example: it is potentially confusing that the application metadata looks like a graphical attribute, "rgb(255,0,0)". Either, 1) use a different example metadata, or 2) explain that this graphical looking thingy is NOT WebCGM standard information, does NOT get graphically interpreted by the viewer (as result of "apply"), but MIGHT lead the application to make some graphical commands to the WebCGM DOM. 1.1.3, coordinate stuff: okay, I'll volunteer for green-box task. Btw, what do you think of calling this coordinate space "Normalized VDC" (NVDC, or NV, or ...). [Lots further down you ask, "How should clientX/Y be worded?" -- I'd suggest to phrase it in terms of NVDC, if people agree to that terminology.] Interface metafile: gives example, "ProfileId:WebCGM,ProfileEd:1.0,Source:A software vendor,Date:20040602,ColourClass:monochrome". This is a nit, but in the CGM it's a string of nested substrings, so for example one valid clear-text CGM representation would be: " 'ProfileId:WebCGM' 'ProfileEd:1.0' 'Source:A software vendor' 'Date:20040602' 'ColourClass:monochrome' ". Now, does that mean you should make it DomStringList in the DOM interface, instead of DomString? Interface picture, IDL Definition: editorial nit, "Node getAppStructureByName(in apsName);" should be NodeList instead (per its method description further down), and similarly should be named getAppStructuresByName. Interface picture, applyCompanionFile() method: "Depending on the parameters, the applyCompanionFile method may or may not 'apply' the XML companion file." Explain? (The statement seems unrelated to the parameter definitions that follow.) Editorial nit: "(coma delimited SDR)" -- be cautious here. SDR has a very particular syntax in CGM. The example given is not a valid SDR. (I'm sure all implementations have SDR handlers, and the given example would break them.) So either: 1.) we want it to be a proper clear-text CGM SDR, or 2.) we want it to be a comma delimited list of integers, whose exact contents depends on the value of the first one (the region type). Note. A proper clear-text SDR is a fairly powerful and useful structure, and could potentially be used for something like the 3-string linkuri's hassle. But it has a somewhat arcane form, not all that user-friendly for hand-editing. [Okay, back to my "coma" now. ;) ] I have a couple more quick comments embedded in the following... At 11:27 PM 7/11/2004 -0400, Benoit Bezaire wrote: >[...] > >New questions (sorry!): > - is it valid to have the 'src' property on the GetWebCGMDocument > interface? > > - I'm still having a hard time with the 'attributes' attribute on > the Node interface. Currently, a script writer would have a real > hard time using this! > > - do we need a removeEventListener method()? Quick scenario to illustrate why we might want/need it? > - highlighting a layer, what happens? Highlight it, just as you would any other APS. (If we allow such, there should be a warning -- be sure you know what you're doing, else you might get an unintelligible mess!) That said, do we want to allow it? Note that 'highlight' functionality is an aspect of the fragment syntax and linkuri behavior. A layer can't be the target of a link, right? So maybe prohibit it for that reason? > - issue, does the interactivity attribute conflict with event > listeners. I support your recommendation in the text (but explanation of why you chose that would be interesting). > - do we need a removeLinkuris and removeNames? Quick scenarios to illustrate why we might want/need them? > - In my opinion, the spec doesn't provide clear enough explanation > regarding coordinate values... what should clientX/Y say? See above (NVDC suggestion). > - What happens if a user clicks on the background of a CGM Picture > instead of on an APS? Anything? Hmmm... there is a list in WebCGM 3.2.1.1 (1st numbered list) of what constitutes a successful "pick". Your question could have a number of answers, depending on whether there's a 'region', what kind of graphical primitive is hit, etc. IMO, this list needs to be reworked for WebCGM 2.0, e.g., for the addition of 'visibility'. SVG's pick rules are much more elaborate, reflecting much more elaborate display/rendering model. But might give some useful guidance here. > >What's still missing (I know I'm forgetting some): > > - architectural illustration. > - rules for applying companion file (we don't have any wording for > that). > - examples & pictures to explain coordinate values of DOM. > - formula for intensity. > - editorial work. > - integrating DTD with spec (not really sure how the entire spec > should be organized). I have an AI to investigate same question and make a proposal for all of WebCGM 2.0, of which this is a big part. All for now, -Lofton.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]