Re: More comments Level 3 Validation/Edit

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