W3C home > Mailing lists > Public > www-dom-ts@w3.org > June 2001

SV: First pass at generated schema for DOM 1 + HTML

From: Dimitris Dimitriadis <dimitris.dimitriadis@improve.se>
Date: Tue, 5 Jun 2001 20:43:07 +0200
Message-ID: <9F67DC27F4CCD311ABA600508B6A66A44A66E5@VXOIMP1>
To: "'Arnold, Curt'" <Curt.Arnold@hyprotech.com>, "'www-dom-ts@w3.org'" <www-dom-ts@w3.org>
comments inlined

-----Ursprungligt meddelande-----
Från: Arnold, Curt [mailto:Curt.Arnold@hyprotech.com]
Skickat: den 1 juni 2001 08:09
Till: 'www-dom-ts@w3.org'
Ämne: RE: First pass at generated schema for DOM 1 + HTML


[mb] Please forward details on how this would happen.  I am reading
it as the transformation that generates the code would have to read
both the instance test definitions and the DOM spec, look up for each
method what the returnType should be, and then generate the code.
On the other hand, if we specify them in the schema def, they will
be visible in the instance, and accessible to the transformation
directly
without having to go elsewhere.

Something like:

<xsl:transform>
<xsl:key name="methods" match="document('domdef.xml')//method" use="@name"/>
<xsl:key name="attributes" match="document('domdef.xml')//attribute"
use="@name"/>

<!--  specific constructs for all language elements -->
<xsl:template match="assign">
</xsl:template>

<!--  if this gets executed then it must either be a DOM method or an error
-->
<xsl:template match="*">
   <xsl:variable name="method" select="key('methods',name())"/>
   <xsl:choose>
      <xsl:when test="not($method)">
          <xsl:variable name="attribute" select="key('attributes',name())"/>
          <xsl:choose>
              <xsl:when test="not($attribute)">
          <xsl:message terminate="yes"><xsl:value-of select="name()"/> not
recognized.</xsl:message>
               </xsl:when>
....
          </xsl:choose>
      </xsl:when>
      <!--  defined in only one location  -->
      <xsl:when test="count($method) = 1">
          <xsl:call-template name="produce-method">
              <xsl:with-param name=method" select="$method"/>
          </xsl:call-template>
      </xsl:when>
      <!--  defined in multiple locations, pick one base on interface
attribute  -->
      <xsl:otherwise>
          <xsl:call-template name="produce-method">
              <xsl:with-param name="method"
select="$method[parent::interface/@name=@interface"/>
          </xsl:call-template>
      </xsl:otherwise>
   </xsl:choose>
</xsl:template>

The produce-method (or produce-attribute) would be passed the appropriate
element from the DOM definition, so it would have the return type, the
attribute order and type, etc.

[dd] OK, that much I understand. But quite honestly, I still don't get why
we should roundtrip to the DOM Spec. Why not just put it in when writing the
tests?

What I would expect we would do is to write a transform that extracts just
the interface definitions from the DOM specs to produce the file that I
called domdef.xml.  However that is not essential.

>NOTE:  I don't want to proceed with more than one transformation.
>According to the minutes, NIST has responsibility for the 
Java transformation.  If you plan on writing one as well, 
>let's discuss it, and try to avoid creating a mess
>with the transformation.  I would much prefer the 
>divide-and-conquer method to the
>everybody try everything and try to reconcile things in the end.

Definitely, I have a mental model of what the transforms for most elements
would look like, though nothing coded.  I think I could at
least get a starting template put together while you are working
on translating test definitions.

[dd] I'd gladly help out on this one.

>[mb] Sorry, that's what I get for working without a net (the DOM spec).
>Just glancing
>through, I've picked up the following where the spec says No Return
>Value:

>normalize, appendData, deleteData, insertData, replaceData,
>setAttribute,
>setAttributeNS --

I've checked the last schema and those elements do not have
var attributes.  They may have had them a couple of
iterations ago due to the typo that I mentioned previously, 
but they don't appear to have it now.
Received on Tuesday, 5 June 2001 14:43:49 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 6 April 2009 12:58:44 GMT