Re[2]: [cgmo-webcgm] New draft snapshot

[Benoit Bezaire <benoit@itedo.com>]

Hi Lofton,

I finaly got the time to read the thread... comments inline.

Tuesday, August 10, 2004, 12:54:26 PM, Lofton wrote:

LH> Ben et al,

LH> Here are a few initial comments.  I may send more later, but
LH> wanted to get my action item (attached) circulated.

LH> 0.)  Substantive:
LH> -----
LH> I attach some initial wording for my action item about
LH> Coordinates. It should be clearer now.  Comments welcome.
I like it.  I still believe that an illustration would help.  SVG has
tons of illustrations and examples in its coordinate section and I
think they are useful.

Yes it does word clientX/Y adquately.  The last bit that needs to be
updated will be the width/height attributes on the Picture interface.
They have to be expressed in Normalized VDC.

LH> 1.)  Editorial:
LH> -----
LH> Exception DOMException:  check and fix the (non-)
LH> correspondence between the IDL definition block and the following
LH> Constants' definition,after the INVALID_ACCESS_ERR code.
Ok, I'll do that.

LH> 2.)  Editorial:
LH> -----
LH> s/Returns the Metafile Descriptor/Returns the MetafileDescription/
Ok.

LH> 3.)  Ed   substantive:
LH> -----
LH> (e.g., "ProfileId:WebCGM,ProfileEd:1.0,Source:A
LH> softwarevendor,Date:20040602,ColourClass:monochrome") -- this is
LH> not a validclear text representation of a sample Metafile
LH> Description string. In the WebCGM instance, it must be a string of
LH> substrings, e.g.,
LH> "'ProfileId:WebCGM''ProfileEd:1.0'
LH> 'Source:A software vendor''Date:20040602'
LH> 'ColourClass:monochrome'"
Yes, I know.

LH> That said, do you want the DOM interface to be the same,
LH> i.e., the single string from the Metafile Description element (with
LH> the above structure)?
No they shouldn't be the same in my opinion.

LH>   Or do you want it to be a list of strings?
I just implemented this functionality recently, and I would like to
propose a change to this method.  I think it should return a
DOMStringList.
ProfileId:WebCGM would be one string, ProfileEd:1.0 would be another,
etc...

I see very little value in the function's current form.  A script
writer would have a real hard time parsing out all that information.
Even with DOMStringList, it's not that simple.  We should maybe
consider new attributes:
profileId -- returns a single string (ex: webcgm).
profileEd -- return a float (ex: 1.0).

But how would you access the optional components?

Comments are welcome.

LH> 4.)  Substantive:
LH> -----
LH> setAttributeNS:  Why have this?  You said (below), 

LH> "- AddedsetAttributeNS().  We were able to set WebCGM attributes but
LH>   not the non-WebCGM one."  

LH> What is an example usage scenario?  It would apparently be
LH> there foradding private (application metadata) attributes to
LH> private (applicationmetadata) elements coming from XML Companion
LH> files.  Why?  Insec 1.1.b we say, "The WebCGM DOM could almost be
LH> perceived as a'readonly' DOM. It is true that some methods on
LH> interfaces allow users tochange an Application Structure style
LH> but, unlike the DOM Level 3specification, it does not allow for
LH> removal or insertion of new Nodesinto the object model."  The
LH> changing of APS styles is a transient effect for (graphical)
LH> viewing and interaction feedback. The changes can't (apparently)
LH> be serialized into a changed WebCGMinstance or changed XML
LH> Companion file -- this WDOM is not anauthoring/editing facility. 
LH> So ... I don't understand the use case for this.
I've read the entire thread on this.  Here's my opinion.

I believe that there's little value in going to all the trouble of
appending namespaced data to APS if we can't assign them new values.
The example that Dieter pointed out is a good one; what if I want to
interactively change the fuse state.  That's why we have
setAttributeNS.

Now answering why allow the setting of namespace attributes and
prohibiting the creation of namespace elements... well we have to draw
the line somewhere.  Rembember that paper presented at conferences
saying that SVG and scripting offers poor interoperability :-)  If we
decide to allow creation of namespace elements we might end up with
interop issues.  I'd also like to point out that implementing
insertBefore, insertAfter, appendChild, createElement etc... is a lot
of work!

The compromise we agreed upon was that the XML companion would add
(i.e., create) namespace attributes and elements.  The getting and
setting of those attributes can be made via DOM methods.

LH> 5.) Substantive:
LH> -----
LH> Appendix C, ECMAscript binding ("ITEDO to supply"):  we should
LH> discuss the schedule for this.  We are telling vendors to start
LH> implementing after tomorrow's telecon.  A binding is needed soon.
Vendors in this group don't need the binding to start implementing.
We haven't completed the binding, we just started the implementation
work.  I think we need the binding for W3C Candidate Recommendation
phase (maybe Last Call).

-- 
 Benoit   mailto:benoit@itedo.com

 
LH> Regards,
LH> -Lofton.


LH> At 01:49 PM 8/3/2004 -0400, Benoit Bezaire wrote:
LH> Hi all,

LH>   Attached you will find a new draft of the spec.  There are nogreen
LH>   boxes in this one, which is a good sign.

LH>   The changes are:
LH>   - Removed the Hyperlink interface.  I couldn't getHyperlinks
LH>   working with the 'attributes' attribute of the Node interfacesince
LH>   Hyperlinks were not deriving from Node.  Instead, I proposethat
LH>   Hyperlinks and 'name's be expressed using DOMStringListobjects.

LH>   - Changed the datatype of the 'value' attribute on the Attr
LH>   interface from DOMString to DOMStringList since we haveseveral
LH>   attributes in WebCGM that can take more than a singlevalue.

LH>   - Changed setters/getters on the AppStructure interface tohandle
LH>   DOMStringList.

LH>   - Added RemoveEventListener on the Picture interface.

LH>   - Removed linkuri specific APIs from DOM.

LH>   - 'src' attribute was moved from getWebCGMDocument interface tothe
LH>   Metafile interface (this is closer to what other technologies aredoing).

LH>   - Changed 'number' datatype to a 'float'.  Number was
LH>   underspecified.

LH>   - Changed 'integer' datatype to 'unsigned short'.  Integerwas
LH>   underspecified.

LH>   - Modified wording for 'namespaceURI', 'prefix' and'localName'.

LH>   - Added setAttributeNS().  We were able to set WebCGMattributes but
LH>   not the non-WebCGM one.

LH>   - 'intensity' is still intensity; here's why...  I tried tocome up
LH>   with other names (whiteout, fadeout, lightness, etc...), but allof
LH>   them in my opinion were prone to be misinterpreted.
LH>   What I did do however, is to make the wording of the spec veryclear
LH>   that this attribute makes colors whiter.  I've inserted theequation
LH>   and added an example to remove any misinterpretation of the
LH>   equation.  If this attribute name is unacceptable to somegroup
LH>   members I'll be happy to change it to something else onceconsensus
LH>   is reached in emails.

LH>   - Added 'pictid' to the Picture interface.  Itedo noticedthat
LH>   pictid is used in linkuris but that they were currently noway
LH>   for accessing a pictid given a Picture object.  It iscurrently set
LH>   as a readonly attribute.

LH>   Please send comments regarding latest draft to the mailinglist.

LH>   My next document will likely be one proposing a set of rulesand
LH>   pseudocode for the applyCompanionFile method.