- From: Dimitris Dimitriadis <dimitris.dimitriadis@improve.se>
- Date: Wed, 30 May 2001 18:15:02 +0200
- To: "'www-dom-ts@w3.org'" <www-dom-ts@w3.org>
I take it this was meant for the list? (with some inlined comments) -----Ursprungligt meddelande----- Från: Mary Brady [mailto:mbrady@nist.gov] Skickat: den 30 maj 2001 17:10 Till: Dimitris Dimitriadis Ämne: Re: First pass at generated schema for DOM 1 + HTML ----- Original Message ----- From: "Dimitris Dimitriadis" <dimitris.dimitriadis@improve.se> To: "'Mary Brady'" <mbrady@nist.gov>; <www-dom-ts@w3.org> Sent: Wednesday, May 30, 2001 9:51 AM Subject: SV: First pass at generated schema for DOM 1 + HTML > 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. > Yes, I agree > As an answer to your questions, mary, i think we've decided to support the > IDL-style subset of the DTD and the Schema that have been proposed so far, > so not any of them, but rather a subset of the union of them. > I understand that, but in Curt's last iteration, he had changed to this style. If we were getting close, then I have a couple of folks who can start coding the NIST tests along these lines -- in fact, this is already done for the Node tests. Making minor mods after the fact will be ok. This serves as a sanity check for us so we can get immediate feedback, and be sure that all is accounted for. > One observation: should we state returntypes on methods as we did in the > dtd? or would this be inferable from the schema? > Not sure -- is this inferable? > 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? > How about if we make it required with a default value of the interfaceName that it corresponds to -- that way, we are sure that it is available to the transformation. [dd] I could live with making them required with default values if it doesn't introduce too much overhead. > For the rest I propose the following for immediate action: > > 1. separate the dom ts ml generating parts from the language construct parts > in the schema > 2. write a simple app to run the xsl against all dom source files > 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. > So, modify the transformation to only include the DOM constructs, write an app to iterate over all files (using SAXON), and package it all. I can take a crack at writing the app. [dd] Actually this is taken care of by running the stylesheet against wg-dom.xml which expands all other files. we still need to discuss the packaging issues, though /Dimitris --Mary > /Dimitris > > -----Ursprungligt meddelande----- > Från: Mary Brady [mailto:mbrady@nist.gov] > Skickat: den 30 maj 2001 15:40 > Till: www-dom-ts@w3.org > Ämne: Re: First pass at generated schema for DOM 1 + HTML > > > This looks quite good -- I like the idea of > generating directly from the spec -- is it > the intent that the generated schema will > be equivalent to Curt's latest schema, if > we had updated it to include all of DOM > Level 1? > > --Mary > > ----- Original Message ----- > From: "Dimitris Dimitriadis" <dimitris.dimitriadis@improve.se> > To: "'Curt Arnold'" <carnold@houston.rr.com>; <www-dom-ts@w3.org> > Sent: Wednesday, May 30, 2001 9:16 AM > Subject: SV: First pass at generated schema for DOM 1 + HTML > > > > I've added the simpleTypes > > > > <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> > > <xsd:simpleType name="RangeExceptionCode"> > > <xsd:annotation> > > <xsd:documentation>RangeExceptionCode</xsd:documentation> > > </xsd:annotation> > > <xsd:restriction base="xsd:string"> > > </xsd:restriction> > > </xsd:simpleType> > > <xsd:simpleType name="EventExceptionCode"> > > <xsd:annotation> > > <xsd:documentation>EventExceptionCode</xsd:documentation> > > </xsd:annotation> > > <xsd:restriction base="xsd:string"> > > </xsd:restriction> > > </xsd:simpleType> > > > > to my local Copy as well as preliminary definitions of the followinf > (taken > > from Curt's original schema) > > > > <xsd:element name="dispatchEvent" substitutionGroup="DOMFunction"> > > <xsd:annotation> > > <xsd:appinfo> > > <!--<annot:function featureOf="EventTarget" > > return="boolean"/>--> > > </xsd:appinfo> > > </xsd:annotation> > > <xsd:complexType> > > <xsd:complexContent> > > <xsd:extension base="DOMFunction"> > > <xsd:attribute name="event" type="variable" > > use="required"/> > > </xsd:extension> > > </xsd:complexContent> > > </xsd:complexType> > > </xsd:element> > > <xsd:complexType name="DOMFunction"> > > <xsd:attribute name="obj" type="variable" use="required"/> > > > > <xsd:attribute name="var" type="variable" use="required"/> > > </xsd:complexType> > > <xsd:element name="DOMFunction" type="DOMFunction" abstract="true"/> > > > > and it seems to work fine. I'll continue tuning it and post the result > later > > today. > > > > 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. > > > > /Dimitris > > > > > > -----Ursprungligt meddelande----- > > Från: Curt Arnold [mailto:carnold@houston.rr.com] > > Skickat: den 30 maj 2001 08:53 > > Till: www-dom-ts@w3.org > > Ämne: First pass at generated schema for DOM 1 + HTML > > > > > > I've posted an XSLT transform and a generated XML Schema from the DOM 1 > xml > > sources at http://home.houston.rr.com/curta/domtest/genschema.zip It is > > really fresh and only superficially checked. I executed the transform > with > > SAXON 6.2.2. > > > > It should be pretty easy to generate both XML Schema and DTD's from the > DOM > > specs XML sources and so eliminate the need for XML Schema to DTD > > conversion. However, I started with XML Schema first, as always. > > > > The transform isn't smart enough yet to handle an read-write property name > > that has different types in different uses or methods with different > calling > > signatures in different uses. > > > > I've not tried the transform against the level 2 sources, but I did take a > > quick look at them. There were a couple of issues, first the directory > > entries in the xml-sources.zip file contained "..", for example, one file > > was named "..\..\..\pubtext\xmlspec-v21-dom.dtd". This requires you to > > unpack to a directory at least 3 levels deep. It would also be helpful to > > know what parameters can accept a null string or node. > > > > > > > > >
Received on Wednesday, 30 May 2001 12:15:40 UTC