[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: RE: Caution using XML Schema backward- or forward-c ompati

• From: "Stephen Green" <stephengreenubl@g...>
• To: "Andrew Welch" <andrew.j.welch@g...>
• Date: Thu, 3 Jan 2008 11:27:36 +0000

On 03/01/2008, Andrew Welch <andrew.j.welch@g...> wrote:

...
> <container>
>   <applicability>
>     <details.../>
>   </applicability>
>   <issueDate>...
> </container>
>
> ...which is the way they do it for various plane configurations in
> S1000D (iirc - it was a few years ago now that I did that).  The
> processing application can then filter or ignore markup that's not
> applicable to itself.  Content with no applicability attribute or
> child element is applicable to all.

That sounds a lot, to me, like RDF. So essentially could we say that
what was discussed a bit earlier in this thread about XML + XML_Schema
+ Schematron + (RDF/S and/or OWL and/or data dictionaries and/or
topic maps) would actually be history repeating itself, compared to SGML
+ S1000D and related concepts/technologies? In other words there was
a need to add semantics with some cases of SGML and the same need
exists with similar cases of XML, even with web services and documents.

Maybe we are trying too hard to avoid 'mistakes' of the past by trying
to make do with XML Schema alone. Maybe we should just do the same
as before but aim to do it better and with the benefit of hindsight. Maybe

Maybe XML + XML_Schema + Schematron +
(RDF/S and/or OWL and/or data dictionaries and/or topic maps) is simpler
and better than the equivalent mixes of SGML, etc but maybe less than
that is too simple for many cases. Add to the mix of course the conformance
tests, etc so it can set like concrete and reduce the likelihood of breaking
changes.

>
> Huge markup efforts like S1000D and AvP70 have addressed most of these
> problems, the people that designed that XML also designed the SGML
> before it, and have coped with problems like versioning, multiple
> variations for each country and per plane etc. so maybe learn from
> their mistakes.  They have massive committees that take a long time to
> change a single attribute, and clear definitions to authors about the
> intended use for each bit of markup - I've lost several enjoyable
> hours ensuring that a 3rd level list used roman numerals, unless it
> was within a numbered paragraph, in which case it becomes a 4th level
> list.
>
> Anyway, my point is that for them the markup is the most important
> thing - bigger than all of the applications that process it - so all
> of the applications change when the markup changes.  A new version is
> a big event.
>
> In the vast majority of other cases, changing all of the existing
> applications to accomodate a new consumer of the markup just isn't
> reasonable, which leads to the slippery slope of wedging more
> information into existing markup, or the new consumer just accepting
> the existing markup.
>
>
>
> cheers
> --
> Andrew Welch
> http://andrewjwelch.com
> Kernow: http://kernowforsaxon.sf.net/
>


-- 
Stephen Green

Partner
SystML, http://www.systml.co.uk
Tel: +44 (0) 117 9541606

http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice

• References:
  • RE: RE: Caution using XML Schema backward- or forward-compatibility as a versioning strategy for data exchange
    • From: Len Bullard <len.bullard@u...>
  • Re: RE: Caution using XML Schema backward- or forward-c ompatibility as a versioning strategy for data exchange
    • From: "Stephen Green" <stephengreenubl@g...>
  • Re: RE: Caution using XML Schema backward- or forward-c ompatibility as a versioning strategy for data exchange
    • From: "bryan rasmussen" <rasmussen.bryan@g...>
  • Re: RE: Caution using XML Schema backward- or forward-c ompatibility as a versioning strategy for data exchange
    • From: "Stephen Green" <stephengreenubl@g...>
  • Re: RE: Caution using XML Schema backward- or forward-c ompatibility as a versioning strategy for data exchange
    • From: "Andrew Welch" <andrew.j.welch@g...>