Lists Home |
Date Index |
- From: "Simon St.Laurent" <SimonStL@classic.msn.com>
- To: "Xml-Dev (E-mail)" <firstname.lastname@example.org>
- Date: Sat, 30 May 98 21:15:30 UT
Peter Murray-Rust wrote:
> - should we allow DTD subsets and XSchemas to be mixed in a >
document instance (whether delivered externally or internally)
> - should XSchemas attempt to provide the function of parameter
> entities *explicitly*?
> - should XSchemas encourage the use of *general/text* entities.
> Note we cannot forbid them unless we forbid the use of DTD
> subsets with XSchemas (Q3).
_If_ XSchemas replace DTD usage for a particular application completely, it is
possible that the parser won't know how to deal with general entities declared
the DTD way. I don't think that's likely in the current situation, because
we'll be building on parsers that need to be able to handle well-formed
documents, including entities.
Should the old DTDs become deprecated and parsers no longer support them, this
could be a significant issue. In the current mixed environment (I know that's
optimistic - there is no mix _yet_) I think we can count on non-validating
parsers to support entity handling.
I don't think it's wise for this proposal (1.0) to explicitly provide
replacements for *any* entity mechanisms. Paul Prescod has given a list of
good reasons why text replacement and schemas should be separated. We should
keep in mind that XSchemas will need to operate in concert with text
replacement mechanisms, however.
(Maybe Paul could set up XEntity.)
This still leaves the core question:
>Should the use of traditional DTD entity (and other) notation be
>encouraged in the design, development, and use of XSchemas?
I know that people are going to use traditional notation anyway; should we
encourage it? (I don't think forbidding it makes sense. Not mentioning it
might make sense.)
Dynamic HTML: A Primer / XML: A Primer / Cookies
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)