On 6/25/2018 9:02 PM, Patrick Durusau wrote:
> Right track? Not having explicit semantics?
Explicit semantics are usually lies anyway. The XML core community
tends to come from industries that believe deeply in semantics, and
haven't figured out that most of the rest of the world isn't so fascinated.
(Yes, I spent much of yesterday and will spend much of today modifying
data that fit at the time it was entered to reflect the current
situation, in ways that violate the expressed semantics of the data
structure at the time it was created, and we'll have to adjust the
semantics to fit the data, and not all of the data will be consistent,
and... that's still an improvement)
> The popularity with programmers can't be denied but is that the measure
> for "right track?"
It's not the measure, but it's an excellent sign that XML missed this
supposed target audience. JSON addressed their needs more easily and
more directly.
(XML also missed its supposed Web target audience, and I'm all too
slowly writing about that.)
> Like spaghetti COBOL code, a lack of explicit semantics is a key to long
> term employment, but I don't see that as a good thing. (Not to single
> out JSON, the documentation protocols for Hadoop and family are based on
> C. Yeah, way to go.)
I don't see long-term employment as the particular issue in this phase
of computing. Kind of to my horror and kind of to my happiness, much of
this code is effervescent. It appears, is used, and is refactored
away. Much to my surprise, programmers seem actually willing to accept
that APIs change and are retired, completely replaced, often within a
year or two. That's a dramatic cultural shift that encourages less
formality.
(It also makes my job really difficult at times.)
Semantics, such as they are, are also moving into different forms.
Granularity keeps shifting, and the comprehensive vocabulary approach of
traditional XML spec development seems to be fading in favor of defining
the smallest useful possibility. Managing the smaller parts means there
are a lot of parts, but less overhead for defining how they fit
together. Since programmers are already fitting them together in often
diverse ways with logical code, schemas and friends often duplicate
effort to little purpose.
Also, things like GraphQL are making it easier to see how things fit
together in the queries themselves. What you ask for is likely what you
actually want, and the response tells you if you can get it. The code is
still not the documentation, and the documentation is still terrible,
but GraphQL has a lot of the same readability that made early XML
navigable. (I have other concerns about GraphQL... long story.)
> Authoring angle-bang syntax isn't the difficulty in using XML, although
> it is rumored to be verbose. It's choosing and adhering to a consistent
> semantic that's hard.
In my experience, those difficulties are oversold. Programmers do have
an odd allergy to angle brackets and prefer curly braces, but that's not
the heart of the matter. Programmers have their own mechanisms for
enforcing the semantics of their moment, and don't find the industrial
'consistent semantic' toolkit XML created to be worth the cost.
> Hope you are at the start of a great week!
If I forget the past weekend, so far so good. I hope the garden is
going well!
Thanks,
Simon
