Re[2]: [cgmo-webcgm] DOM question

[Benoit Bezaire <benoit@itedo.com>]

Hi Lofton,

Please see comments inline...

Cheers!

Monday, July 5, 2004, 8:02:35 PM, Lofton wrote:

LH> At 08:13 PM 7/5/2004 +0200, Dieter Weidenbrueck wrote:
>>[...]
>> >-----Original Message-----
>> >From: Benoit Bezaire [mailto:benoit@itedo.com]
>> >Sent: Monday, July 05, 2004 7:45 PM
>> >To: Dieter Weidenbrueck
>> >Cc: CGM Open Technical Committee
>> >Subject: Re: [cgmo-webcgm] DOM question
>> >
>> >
>> >Hi All,
>> >
>> >  I've attached 3 files (2 svg files and 1 html).  Save all three
>> >  files somewhere and open viewers.html.  I'm using an SVG example
>> >  since the same concept will apply for our WebCGM DOM.
>>Agreed.

LH> This is an aside, but I can't find the answer.  As I was looking at this
LH> svg-based example, the getElementById() caught my attention.  I recall some
LH> discussion at Cologne about eliminating it, but can't find any details in
LH> minutes.
We're not removing it completely, only for the metadata nodes, i.e., it
will only work for WebCGM specific nodes (picture, APS etc... where we
know what is of type XML:ID.

LH> Looking at Benoit's latest DOM draft, on Interface Picture there is
LH> getAppStructureById(), which I guess serves the purpose for standard WebCGM
LH> content.
That's our equivalent to getElementById().

LH> Can someone remind me, why we decided to remove 
LH> getElementById()?  (Potentially applicable to XML companion file 
LH> metadata.)  I don't mean to re-open the argument or advocate for it -- just
LH> trying to remember.
Not a problem.  We don't know what is of type XML:ID unless we parse
a DTD or schema; and unfortunately that's a problem.  We don't want to
be 'forced' to parse a DTD.  We know what is of type XML:ID for WebCGM
elements, so by renaming getElementByID to getAppStructureByID, we
solve the problem (i.e., you won't be able to access XML metadata via
an id).

Regards,
Benoit.

>> >
>> >  BTW, the wording of the spec should be changed; the 'name'
>> >  attribute in xhtml has been deprecated... it has been replace with
>> >  XML:ID.  Therefore, to address a specific 'object', a user should be
>> >  referencing the unique 'id'.
>>one more defect for Lofton

LH> Whew!  This is a mess.  I think we misread and/or misunderstood the OBJECT
LH> and PARAMETER element definitions.  The NAME attribute is indeed allowed on
LH> OBJECT in HTML 4.01, but it refers specifically to "--submit as part of
LH> form--".

LH> And following the link from the 'name' attribute in HTML 4 OBJECT 
LH> definition, one indeed arrives at HTML Forms, where it says that the scope
LH> of definition of the 'name' is the containing form.  I.e., it is not
LH> required to be unique like 'id'.  So the WebCGM 1.0 statement, "The CGM
LH> defined by the object tag can be *uniquely* [my emphasis] addressed using
LH> the <name> parameter [sic!] of the object tag" -- that's bogus in several
LH> ways (at least in the HTML context).

LH> WebCGM section 3.4 shows ID as a permissible attribute on OBJECT.  All
LH> examples (in HTML 4) use 'id' to identify the OBJECT (for referencing).

LH> (Then there is a 'name' attribute on the PARAM element, but it's a totally
LH> different thing than instance identification).

>> >  One I'm not a 100% sure about this part of the wording below:
>> >  "However, the specific syntax for addressing a specific CGM in an
>> >  HTML page is not standardized.", in my example I know that
>> >  everything after "document." is completely standardized.  I just
>> >  can't find where the W3C says that a global object called 'document'
>> >  is the DOM entry point.
>>When we wrote WebCGM 1.0 there was no DOM, hence the addressing of a
>>WebCGM viewer was restricted to sending a URL to a frame or window.
>>This would only work of course if the CGM took up the entire frame or
>>window.
>>And even this method did not adress a viewer but rather a container for
>>a viewer, IE would drop the content of that container and then create
>>a new viewer to show the file with the new URL.
>>
>>So the wording should probably be changed to:
>>"...The CGM defined by the object tag can be uniquely addressed using the
>><XML:ID> parameter of the object tag. The WebCGM DOM can then be used to
>>manipulate that specific viewer."
>>
>>One question: Should we add some words about grandfathering of the
>>"name" attribute of the object tag to ensure upward compatibility?

LH> IMO, the 'name' specification in WebCGM 1.0 is an Erratum.  As I noted
LH> above, that referencing text is wrong in several ways.

LH> That said, I'd like to know how vendors would like to treat it, given that
LH> the mistake has been sitting there for a few years.  Approaches could range
LH> from fix it (Erratum fix means "retroactive" in worst case), to 
LH> "grandfather", to somewhere in between, like a non-normative note 
LH> explaining the former glitch in the specification and the fact that there's
LH> probably some legacy content floating around.

LH> -Lofton.


>> >
>> >  Does this help?
>>It does.
>>
>>Thanks a lot,
>>Dieter
>>
>> >
>> >  Cheers,
>> >
>> >--
>> > Benoit   mailto:benoit@itedo.com
>> >
>> >
>> >Monday, July 5, 2004, 7:27:07 AM, Dieter wrote:
>> >
>> >DW> All,
>> >DW>
>> >DW> the WebCGM Recommendation says:
>> >DW>
>> >DW> 3.1.4 Addressing one of several viewers from HTML
>> >
>> >DW> Often, applications will display several pictures in a single
>> >DW> HTML page. The only way to address the cgm viewer instance that is
>> >DW> responsible for the display of a particular picture is via the
>> >DW> "object" tag defined in HTML 4.0. The CGM defined by the object
>> >DW> tag can be uniquely addressed using the <name> parameter of the
>> >DW> object tag. However, the specific syntax for addressing a specific
>> >DW> CGM in an HTML page is not standardized.
>> >
>> >DW> The Document Object Model (DOM) is currently under
>> >DW> development. This work, when completed, is expected to provide a
>> >DW> standard basis for addressing this problem.
>> >
>> >DW>
>> >
>> >DW> Question: How do we address this problem using the DOM as it
>> >is written in the spec?
>> >
>> >DW> Comments?
>> >
>> >DW> Regards,
>> >
>> >DW> Dieter
>> >
>> >




-- 
 Benoit   mailto:benoit@itedo.com