- From: David Brownell <david-b@pacbell.net>
- Date: Wed, 01 Mar 2000 15:27:14 -0800
- To: Dieter Köhler <dieter.koehler@ppp.uni-bamberg.de>
- Cc: "www-dom@w3.org" <www-dom@w3.org>
Dieter Köhler wrote: > > > As for PIs ... they're either built in to the application (e.g. > > ones marking an editor cursor) or levarage the NOTATION mechanism > > half-suggested for that purpose, and so must appear after the DTD. > > As I wrote in an earlier post: Creating customized external DTDs is a > legitimate use of PIs before the DTD. That's the "built in to application" scenario. Though in this case you're expecting some parse-time interaction _with a parser_ which is currently out of scope for DOM ... it's not a parser API, and doesn't provide a way to access a parser. > Beside that: The minimum requirement for a final DOM version is that > it offers a way so that each well formed XML document can be parsed > properly. For L1 and L2, the requirement is to _represent_ the document properly. Parsers are (or in some cases "should become") separate components. You can give a DOM as output of a parser if you want, but that's not required. Parsers can use DOM APIs to construct a representation. You're talking about some structure where the application can perform an interaction with the parser; doesn't really matter how the parser and DOM interact, or if DOM is an output (though it's the model you've presented). In this case, when the app gets your magic PI from the parser, and knows to create the DTD external subset ... it won't need to do anything else, but it needs to do that mid-parse, before the parser has started to try to read whatever is after the PI (e.g. DTD). > What you demand is a stricter XML version which forbids PIs > before DTDs. Nope, not at all. See above. - Dave
Received on Wednesday, 1 March 2000 18:27:11 UTC