Re: [xml-dev] The Goals of XML at 25, and the one thing that XML now nee

[Arjun Ray <arayq2@gmail.com>]

 On Tue, 20 Jul 2021 13:04:34 +1000, Rick Jelliffe
<rjelliffe@allette.com.au> wrote:

| May I  argue that keeping data content untyped strings (i.e. you need a XMP
| Schema or casting to determine its type) but allowing limited basic typing
| of attribute values in no way compromises any theory of what tagging should
| be used for what purposes?

Sure.  My "rule" about attributes was meant as advisory only!  Further
along in the thread I cited (but which needs the thread index to find,
thanks to the bogotic handling of references in mail agents back then)
is a somewhat fuller explanation:

    http://lists.xml.org/archives/xml-dev/200205/msg01043.html

The schema folks drove everything off the rails by introducing the
notion of "data typing" for attributes.  This also instantly mystified
the older declared value typology.  But it had the (possibly intended)
effect of solidifying the "use case" of attributes for ordinary data
values.  Never mind the untold legions of Microserfs who learned the
"right way to do it" from gems of cluelessness such as this, graced
with the imprimatur of a W3C Note:

    http://www.w3.org/TandS/QL/QL98/pp/microsoft-serializing.html

Bolting barn doors and all that.  If (limited) data type recognition -
true numbers and booleans - is to be pushed into the parsing layer,
then we probably need a proper set of syntactic signals.  I don't find
the "low hanging fruit" argument particularly persuasive.

| I like this syntax idea (unquoted attribute values have defined lexical
| types) not because it would compete with JSON more, but because it would
| take a clue from JSON and make traditional SGML-style publishing systems
| easier: particularly in internal pipelines which are inevitable done with
| no formal DTD or schema (i.e. normalized data.)

I'm not sure I understand this.  Implicit conventions are quite common
in internal pipelines.  The conversions from text to other data types
has to happen somewhere; I'm not seeing why it's easier overall for
this to be in the parser.  Or maybe I'm not getting the point here?