XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] A few quotes for the xml-dev Hall of Fame

From such a long discourse, the two that most old out for me were from
David Lee and Simon St. Laurent :-

----------------------------------------
David Lee wrote:-

What Is XML ?

I see a strong disconnect here, very opinionated, and in my mind *both right*.

On the one hand:

1) "XML is precisely what the specs say it is, no less and no more".

This is strictly true, and I respect this immensely.  In fact 90%+ of
the time it's also the more useful perspective because most questions
'about XML' are about precisely this 'What do the specs say is really
a proxy for "Why doesn't my code work"

But, I beg to offer a different perspective, one Hans is hinting at

And here I will admit I am mis-using a term intentionally which I
actively dislike in general but allow me this for a moment  before I
revise it

2) "XML is a powerful abstraction that allows people and technologies
to interoperate at a high level using a well-defined data model (XDM),
where the text serialization is but one representation and not
necessarily the important one."

Which is strictly untrue but I argue its useful and the  bone of
contention is not the concept but rather the terminology.

----------------------------------------------
Simon St. Laurent wrote :-

There are multiple ways to process and examine a given XML document,
as Rick Jelliffe noted:

* Text
* Event streams
* Graphs of nodes
* Trees of nodes

The "syntax view" keeps the possibilities of that first option open.

* It reminds us that we are indeed 'marking up' documents that may
have cohesive value on their own, not just as shredded and codified
chunks of data.

* It recognizes that broken and incomplete documents may yet contain
especially important information.

* It leaves the door open for information that didn't fit in someone's
prized model, allowing for format evolution rather than cycles of
standardization.  The structure of a given document is almost always
easier to change than the programs that process it.  (The nodes view
emphasizes the priority of programs and all too often celebrates the
things that make them brittle.)

* It makes comprehensible possibilities that can't be reached if you
lock yourself into nodes from the beginning.  Overlap is the place I
see this most often.  Programmers indoctrinated into neat structure
often see this as an utter corner case, but those who work with human
documents know it exists regularly in the wild.

On 17/11/2013, Costello, Roger L. <costello@mitre.org> wrote:
> Hi Folks,
>
> I picked out a few of my favorites from the ongoing discussions.
>
> ------------------------------------------
> Michael Kay wrote:
>
> In ordinary discourse we often allow semantic drift in the way we use
> terminology, but in computing I think it's best to be very clear about what
> our technical terms mean, and when someone invents a term like "XML" and
> provides a definition, I think it's sloppy practice to use the term to mean
> something different.
> ------------------------------------------
> Rick Jelliffe wrote:
>
> Information architects reading might be interested that here in Australia we
> are increasingly having to deal with people's names from our vibrant
> neighbor Indonesia, where people commonly have a single name only (e.g.
> Munali). It is not a family name, not a surname, and not a second name.
> This causes some bother, because many local computer systems are designed to
> require two names.
> ------------------------------------------
> Toby Considine brought to our attention the term English-prime (E-Prime):
>
> E-Prime (short for English-Prime, sometimes denoted É or E′) is a
> prescriptive version of the English language that excludes all forms of the
> verb to be. E-Prime does not allow the conjugations of to be—be, am, is,
> are, was, were, been, being— the archaic forms of to be (e.g. art, wast,
> wert), or the contractions of to be—'s, 'm, 're (e.g. I'm, he's, she's,
> they're).
>
> Some scholars advocate using E-Prime as a device to clarify thinking and
> strengthen writing. For example, the sentence "the film was good" could not
> be expressed under the rules of E-Prime, and the speaker might instead say
> "I liked the film" or "the film made me laugh". The E-Prime versions
> communicate the speaker's experience rather than judgment, making it harder
> for the writer or reader to confuse opinion with fact.
>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS