From: "Bullard, Claude L (Len)" <>
> This is like the XML subset issue: if we create subset
> only parsers instead of insisting that the
> application language designer take on the
> responsibility of choosing which features should
> be used and documenting that carefully (the
> document approach), we can seriously break
> the contracts that XML systems be easy to
> apply, have minimal options, and flatten
> out the footprint of code types
But XML is broken for that anyway: because standalone="yes"
is voluntary and probably ignored by recipients anyway, you cannot
guarantee that if you need to take advantage of XML's expressive
power (e.g. use entities, attribute defaulting, external subsets, etc)
the receiver will end up with the same infoset.
The result is this cart-before-the-horseism that vomits itself up
on XML-DEV every few microseconds: "I want to get rid of
the parts of XML I don't use". Rather than "Lets fix the parts
that are broken", which is constructive and congenial.
Now we have had five years of XML, we can see that there are
three main communities who are not well-served by the current
well-formed/valid distinction in XML: at the dumb end of town
are the SOAP people who don't need entities or a DOCTYPE declaration;
at the middle of town we have the XHTML people who do need
entities but don't need validation (or who will be switching to some
other XML schema language such as ISO DSDL instead of DTDs);
and at the grand end of town, the Schema and Query people wish
DTDs could go away faster.
Solution? W3C should
1) Deprecate Well-Formedness for public specs, documents and
data interchange (it is a niche thing only suitable for editors); and
2) Give a formal name for a headless XML, in which a DOCTYPE
declaration is an error (and make it a little simpler: don't check
naming rules or normalization) SOAP can use this.
3) Give a formal name for an unvalidated, guaranteed-infoset XML:
all parameter entities fetched, defaults applied, entities defined,
IDs typed, but content models not checked. XHMTL can use this.
That addresses the core issues with XML for SOAP, XHTML and
Schemas, as I understand them (ignoring issues that come down to
saying XML should be completely different). It is minimal and requires
no syntax changes to existing documents. Existing parsers can still
muddle along as present. So it is very non-disruptive.
Solutions like "get rid of attributes/entities and everything will be well"
look like armchair speculation to me: the trick is not to come up with
a tidy idea, but to come up with a practical one that moves us forward.
Cheers
Rick Jelliffe
