> PP> Resources (namespaces, characters, entities, etc.) are one thing.
> PP> Constraints are another. I'd like to keep them separate.
>
> JC>And I would like to keep them together. A matter of taste.
>
> Unfortunately, I think it's a lot more than a matter of taste. Making XSchemas
> perform text substitutions requires a much more complex processing model.
It's also a matter of what our goals are. My original hopes for XSchema were
relatively modest -- I wanted a standard way to explore DTDs. A side-effect was
that parsers could use the information for validation. I also had some vague
hopes for schema reuse and laying a foundation for strong typing.
When John pointed out that you couldn't validate an XML document without
entities and notations, I had to agree and added both to my DTD. It simply
didn't occur to me that such validation would be done outside the parser -- the
back-and-forth between XML applications and parsers described by John and Paul.
I just assumed that validating parsers would, in the future, read XSchemas as
they now read DTDs.
Having now read the multitudinous arguments on each side, I have come to the
conclusion that entities don't belong in XSchema for two reasons:
1) Requiring that a parser include information (an entity definition) from an
XSchema document just to get a well-formed document is a bad mistake.
Evolutionary steps that require you to throw away existing software don't have
much chance of success.
2) I find the view of XSchema-as-schema far more compelling than XSchema-as-DTD.
Although both fit my original goal (DTD exploration), XSchema-as-DTD is a dead
end, while XSchema-as-schema is a building block for the future.
-- Ron Bourret