- From: Curt Arnold <carnold@houston.rr.com>
- Date: Mon, 02 Jun 2003 22:45:19 -0500
- To: "Benjamin C. Chang" <Ben.Chang@oracle.com>
- CC: www-dom@w3.org, w3c-dom-wg@w3.org
Benjamin C. Chang wrote: >Responses are below. > >Thanks, >Ben > >Curt Arnold wrote: > > > >>ElementEditVal.allowedChildren isn't all that useful. What you really >>would want is a list of all the element names (and maybe #text if >>character content would be allowed) that could appear as the initial >>child of the element. If you had a content model like (j, >>(a|b|c|d|e|f|g|h|i|k|m|n|o|p)) you would want to guide the user to start >>a <j> element. Once you had that inserted, you could use >>NodeEditVal.allowableNextSiblings to guide through the rest of the >>content model. >> >> > >allowedChildren is very flexible; subsequent operations would achieve >your desired results. Your suggestion of having a convenience attribute >(the allowed* are all attributes) allowedFirstChildElements was >incorporated. > > > >>ElementEditVal.allowedAttributes is good, but it would also be helpful >>for have an ElementEditVal.requiredAttributes and maybe an >>ElementEditVal.fixedAttributes. >> >> > >requiredAttributes was already there; you must have missed it. We decided >against adding a fixedAttributes attribute for now. > > > >>It would be useful if DocumentEditVal had a method that took a value >>from a NameList from allowedChildren, allowedNextSiblings, et al and >>created the corresponding node. The format of the NameList entries is >>not described, but without such a method, it would be necessary to parse >>the entry into the namespace and local name and then call the >>corresponding CreateElement or CreateElementNS. >> >>Something like: >> >>Node CreateNode(string nameListName) >> >>where if nameListName was '@foo', you'd get an attribute, if >>nameListName was #text, you'd get a CharacterDataNode and if >>'transform:http://www.w3.org/1999/XSL/Transform", an XSLT transform >>element and if "foo" a DOM L1 element. >> >>That would suggest that allowedAttributes should return the attribute >>values starting with a "@". You'd also need to specify how you'd >>represent namespace qualified attributes. >> >> > >If you take a look at the DOM L3 CORE NameList description, these >are not needed. > > > > > The proposed name allowedFirstChildElements seems inconsistent with name allowedChildren. Other than that, I am satisified with the resolution. Apparently I did overlook requiredAttributes. I agree that fixedAttributes is excessive, The current public working draft of L3 Core does not define NameList. I assume that it is defined in the current working group draft. If NameList has a provision to creation of nodes from a name entry, then I would be satisified with the resolution. I do believe it would be essential to have a coordinated release of a Core public draft with the next public working draft of L3 validation.
Received on Monday, 2 June 2003 23:45:18 UTC