- From: <keshlam@us.ibm.com>
- Date: Thu, 30 Jul 1998 16:12:58 -0400
- To: www-dom@w3.org
More stuff from the sanity-check pass (as long as I'm swapping it all into wetware anyway...) Text: Currently says that it's the non-markup content of an element, and that markup will be siblings on either side of it. Two problems with that statement. (1) It may be the content of other things, eg Attribute. (2) It may be only one contiguous chunk of that content. There may be more than one text child separated by markup: As in <strong>this</strong> case, where the siblings are Text, Element, and Text again. Current wording suggests only a single Text should be expected except during editing; not what you intended. Has joinText's behavior been nailed down since the 20th? Somehow, having it return an orphan Text doesn't seem to save a lot of work versus cloning the first and appending the data from the second. ProcessingInstruction: You might want to make more explicit that the target re-appears as part of the data... and remind folks about the PI's syntax, eg whether or not whitespace is allowed between <? and the target. (I'm somewhat surprised that you offer target alone, and all-data, but _not_ data-following-the-target. It would seem appropriate, if you're going to go to the trouble of parsing out the target, to offer both results to the user.) DocumentType: Should this be self-initialized to include standard entities such as %lt;? Or is it assumed that whoever creates the Document will take responsibility for setting this up correctly? (The latter is more general, but since these extended classes are XML-specific...?) Might be worth pointing out once again that the DOM explicitly doesn't discuss creation of the root Document, and only operates on it once it exists, just to avoid questions about who shaves the barber.
Received on Thursday, 30 July 1998 16:12:51 UTC