Re: KML is very extensible ... but why?

Simon,

"...we never stop thinking, and brittleness is not a virtue."

True but then academics never stop building artificial (in my opinion) walls that slow down or prevent the sharing of data. There are a variety of motives for such acts and I for one am not generous when assigning them. So I will pass over motive and simply observe that it happens.

Perhaps less so now with some of the open data projects but I have known of major resources programmed entirely in VB and not stored in XML, primarily because the spouse of the academic was a VB programmer and sharing of the data wasn't a goal.

From my perspective (what other one would I have?), idiosyncratic extensions are a reflection of a lack of thinking, adding noise to markup when *thinking* about existing mechanisms could have resulted in a non-extension answer. Movement or change isn't a sign of thinking, just movement or change.

Gaps and failures in standards exist from their first drafts to the last corrigenda. So changes/extensions are always necessary, I'm quibbling about a state, which Stanley Fish would say, never exists, that is "anything goes." We are always bound by our communities of discourse and so "anything goes" really isn't possible.

Sigh, I really hate it when I talk myself out of my position in an email. ;-)

Hope you are having a great week!

Patrick

On 4/24/2018 2:12 AM, Rick Jelliffe wrote:

Sorry about typos. Giant fingers  tiny screen.

Don't worry at all.  That fit the conversation perfectly.

Is part of what you are identifying a manifestation of the paradox of standards?   Standard processes say they are at heart an agreement. But if you come along too late, the deal is done. And the standards stop being an agreement but an imposition, even for voluntary standards

Sometimes "too late" is not the week after ratification, but the week after the first technological meeting!

That is part of it, a part that can certainly make things worse.  At heart, though, I'm saying that standards are themselves paradoxical.  We put tremendous amounts of effort into building brittle boxes and workflows for ourselves and celebrate that we can lock ourselves down so successfully that we're allowed to stop thinking.

Except that we never stop thinking, and brittleness is not a virtue.

Thanks,
Simon

On Mon, 23 Apr 2018, 20:35 Simon St.Laurent <simonstl@simonstl.com> wrote:

I like these, though I think autocorrect has done some strange things. 
I'll reply as I think it it was meant, and let me know if I'm wrong in
my guesses about the questions in addition to my answers.  (Which fits
the topic perfectly, actually!)


On 4/23/2018 12:31 AM, Rick Jelliffe wrote:
> Two quickies.
>
> Shared synth good, shared semantics bad. But does a schema really
> special syntax?

This reminds me of an angry comment from someone after a Walter Perry
talk long ago.

"Doesn't he know that today's semantics are tomorrow's syntax?"

It can work like that, but I don't think it has for a while. Perhaps
we're just in a lull.  I read schemas as an effort to make that kind of
shift, but I don't see that shift happening.  Or, for now, profitable.

> Does a schema share semantics or just advertise them?

Too many people on too many projects have claimed that sharing (and
standardizing) the meaning of things is the point of schemas.  It seems
to work better for gathering funding.

While people are certainly willing to pay for advertising, I don't think
that is what they often claim to be doing here.  Worse, we seem to live
in a world in which we can give people advertisements and they mistake
them for stern reality.

Schemas can absolutely be useful, but our tendency to make them into
prisons also makes them dangerous. (And yes, people say that XML syntax
is similarly imprisoning.  I tend to disagree about that part, but don't
worry much about convincing them any more.)

Thanks,
Simon

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

-- 
Patrick Durusau
patrick@durusau.net
Technical Advisory Board, OASIS (TAB)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)

Another Word For It (blog): http://tm.durusau.net
Homepage: http://www.durusau.net
Twitter: patrickDurusau