Re: [cgmo-webcgm] New draft snapshot

[Lofton Henderson <lofton@rockynet.com>]

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.