Re: [Design] New proposal for DOM TS ML

----- Original Message -----
From: "Arnold, Curt" <Curt.Arnold@hyprotech.com>
To: "'Mary Brady '" <mbrady@nist.gov>
Sent: Saturday, May 26, 2001 1:34 AM
Subject: RE: [Design] New proposal for DOM TS ML


> >In some cases, there are no defined return values, parameters, etc
> >since in this go-round, we have an element for each method/attribute,
> >we can be disciminate in what is defined -- this is consistent with the
> >DOM spec.  In the interfaces that I've been through, it happens much more
> > so than you might think -- just scan the IDL def's for anything of type
> >void -- having the correct info available to the transformation makes
> >for cleaner generated code -- if that's possible :-).
>
> If the type is void, I didn't have a "var" attribute for the return value.
In the previous post, I interpreted you saying that you made the "var"
attribute optional in cases where their was a return
> value, so you could so something like:
>
> <item obj="nodelist" index="2"/>
>
> That is get the third element in the node list, but not assign it to
anything.  This might be appropriate when you are expecting an exception.  I
originally made it optional, but it was so bothersome
> having to manually fill it in that I switched it to required.
>

[mb] No- not at all -- I made it non-existent in cases where there was no
return-value.
In some methods -- you just make changes to the DOM tree - and nothing gets
returned.
It was in these definitions that I left it out completely -- same goes for
DOMException
and returnType.  If the method has a returnType of boolean, I think I
defined it as #IMPLIED --
otherwise, I believe it is #REQUIRED.

>
> >[mb] If you account for inheritance, the same method /property names
> >should occur in lots of places.
>
> The key thing is what interface initially defines it.  In this case of
getElementByTagName it is defined in two different places in the hierarchy
and these two bits of code will have significantly
> different behavior:
>
> Object test = ...;
> Object address = ((Document) test).getElementsByTagName("address");
> Object address = ((Element) test).getElementsByTagName("address");
>

Yes, and currently, or as soon as Dimitris does the Document interface, they
will have
two different definitions.  I understand that this would have been an issue
in your
schema def, and would have indicated the need for
Document.getElementByTagName
and Element.getElementsByTagName -- or the other method, which you see in
the
currently floating dtd <Document><getElementsByTagName ...></Document>

> However, other than an additional instanceOf check, the following are
indistinguishable:
>
> Object data = ((CharacterData) test).getData();
> Object data = ((Text) test).getData();
> Object data = ((ProcessingInstruction) test).getData();
> Object data = ((Comment) test).getData();
>
> Since the all reference the same method which is defined in the
CharacterData interface.
>

[mb] The issue of inheritance was raised early on on this list -- I'd have
to go back through the
archives to see where, and at that time at least some folks wanted to see
tests for these
methods on each interface where they can occur.  In some cases, the NIST DOM
tests
do this in some cases, albeit they are hidden in the Node tests, as opposed
to the specific
interface in which they are inherited.

> If you want the equivalent of the last line for example, it simplifies the
language to do it as two operations, on to check if it is an instance of
Comment and once to invoke the
> CharacterData.getData() method.
>
>
> <assertInstanceOf obj="test" type="Comment"/>
> <!--  invokes CharacterData.getData   -->
> <data var="data" obj="test"/>
>
>

[mb] Really -- you find this more straight forward than making the method
available as such
<Comment><getData ...></Comment>
<assert ...>  <-- of course the assertion elements are as yet to be defined,
but I expect that they
                          won't be much different from what you already
have.

> The only places where I think there are the same names being used for
distinct methods or properties and the getElementsByTagNames,
getElementByTagNamesNS and the code attributes in the exceptions.
> As long as these are disambiguated with the class name, then there is no
need to have the interface name represented in the other calls.
>

--Mary

Mary Brady
NIST, Web Technologies
mbrady@nist.gov

Received on Saturday, 26 May 2001 08:35:19 UTC