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 04/25/2018 06:42 AM, Simon
St.Laurent wrote:
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
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
