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

> <xsd:simpleType name="DOMExceptionCode">
> <xsd:annotation>
> <xsd:documentation>DOMExceptions raised</xsd:documentation>
> </xsd:annotation>
> <xsd:restriction base="xsd:string">
> <xsd:pattern value="[A-Z][_]*"/>
> </xsd:restriction>
> </xsd:simpleType>

I think that was already generated as ExceptionCode (which was its name in
the xml source),  Maybe I didn't synchronize with <assertDOMException/>.

> <xsd:simpleType name="RangeExceptionCode">
..
..
> <xsd:simpleType name="EventExceptionCode">
..
..
>
> <xsd:element name="dispatchEvent" substitutionGroup="DOMFunction">
..
>
> and it seems to work fine. I'll continue tuning it and post the result
later
> today.

These were all defined in DOM Level 2, so they weren't generated here.  They
would be there if ran against DOM level 2 sources.

> I have som eproblems with my source files, though, for example the
> Document.xml for level 1 doesn't have a root node. This goes for some of
the
> HTML interfaces as well.

Should have mentioned this, most of the .xml files are external parsed
entities, I generated the schema by running the transform against wg-dom.xml
which expands all of them.

>I think we should create a thread to discuss exactly what vocabulary we
>intend to produce. Generating directly from the schema lets us use the
>native inerface and method names. I'd like to see that we do this

Could you give some examples, I'm not sure what you are proposing.

>One observation: should we state returntypes on methods as we did in the
>dtd? or would this be inferable from the schema?

It would be inferable if the wg-dom were available during the transform.
I didn't put in the <annot:function return="DOMString"/> from the manual
schema since I thought it might be preferable to directly reference the
spec, but it may be preferable to work against the schema since the specs
representation may evolve and we might have done some tricks to combine
pieces
of various specs.  Using a returntype attribute breaks down for Event.target
and ProcessingInstruction.target.

>Another question is if we shouldn't still state interfaceName/methodName,
>even in cases where this is reduntant. This I think is easier to write in
>the schema. Your views?

For lack of time, I did not add an optional interface attribute when the
property
or method was inherited.

I think the current approach is pretty optimal from an authoring and
readability perspective,
though it adds some complexity to the schema generation and code generation
process.  Either
<Interface.Property/> or <Interface><Property/><Interface> is awkward since
you
think primary in terms of property or method names.

>1. separate the dom ts ml generating parts from the language construct
parts
>in the schema

Again, a lack of time issue.  Something like:

<xsl:transform>
    <xsl:template match="/">
        <xsl:call-template name="static-content"/>
        <!--  generated content goes here -->
    </xsl:template>
    <xsl:template name="static-content">
        <!--  all the fixed stuff goes here -->
    </xsl:template>
</xsl:transform>

>2. write a simple app to run the xsl against all dom source files

I'm not sure that you need this in the DOM Level 1 sources if
you run against wg-dom.xml.  If you are trying to create a schema
for DOM Level 2 Core + Events + Range, you may need to build
a base file that includes the appropriate files from each spec.

>3. collect the schema snippets into one file, or create a master schema
>(perhaps with the constructs and the packaging/suite info) and include the
>other files.

There is definitely some packaging issues to deal with.  Especially, when
we start looking an extended DOM interfaces like those in SVG.

Received on Wednesday, 30 May 2001 11:23:22 UTC