XML processing experiments
Jarle Stabell
jarle.stabell at dokpro.uio.no
Sun Nov 9 22:53:07 GMT 1997
<Tim_Bray>
At 07:11 PM 08/11/97 +0700, James Clark wrote:
>> If "foo" is an *internal* entity, the spec clearly requires your
>> parser to expand it for the application. ...
>
>I think it's also fine to give the app control over when the parser
>performs the expansion.
This may be the case, but it's not what the spec says today. From
4.4 in the 970807 version:
For an internal (text) entity, the processor must include the entity;
that is, retrieve its replacement text and process it as a part
of the document (i.e. as content or AttValue, whichever was being
processed when the reference was recognized), passing the
result to the application in place of the reference.
</Tim_Bray>
[JS] Some apps needs entity expansion *not* to happen, so I think the spec
shouldn't forbid the processor to let the app decide upon this. (I can't see any harm in this, just a *very* useful feature for those apps which needs it.)
F.i. authoring tools which loads the documents into some sort of "structured editor" shouldn't "flatten" the document if the user doesn't want this.
Same applies to tools which updates documents, f.i. synchronizing documents with respect to other data (data in a database etc).
(Converters may also want entity expansion not to happen)
Of course, one has to add some special logic to the processor in order to fully validate/check the document in this case (or just validate it up front with a "normal" parse (if validation is necessary at all), followed by "semi-parsing" it with "no-expansion")
Cheers,
Jarle
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)
More information about the Xml-dev
mailing list