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] Not using mixed content? Then don't use XML

>>In large part, this is because the developers in question are from
multiple international institutions collaborating voluntarily, are skilled
and independent-minded, and are plugging the XML into >>existing legacy
systems on not enough funding (so, nothing unusual!).  And because everyone
knows about Postel's rule, and is generally averse to brittleness.  An XML
schema enthusiast would >>presumably say that strict(er) schema validation
would help with each of these things, but... that's not how it's working
out.


And that's the thing about some of the repeated assertions on this
thread-especially that standard specifications are always waterfall. I would
be lying if I indicated I haven't seen some immense XML whose complexity and
poor definition was intended more to keep out interlopers than to enable
interaction. Still, that is not what I have seen to be best practice.

The best (meaning most likely to be widely adopted and successful)
specifications start with existing practice. It may be your JSO, and someone
else's field manual and someone else existing business transactions. While
there are some similarities, they are incompatible in some ways. Often they
have parts that are over-specified, as Simon describes. Sometimes they have
aspects that are simply unintelligible to potential partners. Other times,
the incompatibilities are similar to those in the old big-endian
little-endian wars, that do not reflect any underlying mismatch. 

Rather than a waterfall, a successful specification effort (as defined
above), IMO, strives to find the overlaps, to define the
incomprehensibilities, and to eliminate the superfluous. It may also define
how to extend, and how to indicate what a receiving party should do if it
does not understand the extension. This is the opposite of waterfall.

"A designer knows he has achieved perfection not when there is nothing left
to add, but when there is nothing left to take away."
-Antoine de Saint-Exupery

tc



-----Original Message-----
From: Norman Gray [mailto:norman@astro.gla.ac.uk] 
Sent: Monday, March 25, 2013 5:34 PM
To: David Lee
Cc: xml-dev@lists.xml.org
Subject: Re: [xml-dev] Not using mixed content? Then don't use XML


Greetings.

On 2013 Mar 25, at 18:03, David Lee <dlee@calldei.com> wrote:

>>>>> 
>>>>> 
> What miraculous corner of the markup world do you live in?
> 
> Can we expand that corner?
> 
> <<<<<<<<<<<<
> 
> A Corner very near my corner.
> 
> I have worked with XML for 15 years and only *occasionally* have had to
touch a schema.
> Even now working deep in the depths of an enterprise XML Database company
my use of schema is primarily a QA exercise, [...]

Ditto.

I've been doing SGML and XML things since SGML-on-the-web was the coming
thing, and what XML stuff I still do is in the context of an
interoperability standards grouping for Astronomy (http://ivoa.net).

The IVOA is rather XSchema-obsessed, most of its Recommendations come with
some sort of XSchema document, and many of the data-modelling arguments are
articulated (woe is us) in XSchema terms.  Even with all that, however, I
feel that the schemas are pretty marginal in practice.

One way they're useful is because you've got to have _some_ way of
expressing an agreement about legal XML structure.  They're used to settle
arguments ('that's not a valid message because of line xxx of the schema!';
'oh bugger, you're right, but you know what I mean...').  I think some
people do use them for code-generation of one type or another.  But I
suspect that most of the systems parsing the schema files are wetware.

In large part, this is because the developers in question are from multiple
international institutions collaborating voluntarily, are skilled and
independent-minded, and are plugging the XML into existing legacy systems on
not enough funding (so, nothing unusual!).  And because everyone knows about
Postel's rule, and is generally averse to brittleness.  An XML schema
enthusiast would presumably say that strict(er) schema validation would help
with each of these things, but... that's not how it's working out.

I suppose that Postel's rule in this context is saying that valid/invalid
isn't as binary as one might expect.

All this is separate from the question of what syntax we should be using (is
that this thread or the parallel one?).  XML isn't perfect for this (there
are several places where (I assert) something like RDF would be a much more
natural fit, and some folk push UML-type things), but it's expressive
enough, everyone groks it, there's decent tool support, and we use other
formats for the real heavy lifting.  This isn't very interesting XML usage
-- but XML stopped being Interesting a decade or so ago -- but it works, and
schemas are not central to it.

All the best,

Norman


-- 
Norman Gray  :  http://nxg.me.uk
SUPA School of Physics and Astronomy, University of Glasgow, UK


_______________________________________________________________________

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




[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