Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


Re: [xml-dev] RE: Caution using XML Schema backward- or forward-c ompatibility as a versioning strategy for data exchange

From: "Stephen Green" <stephengreenubl@-----.--->
To: "Andrew Welch" <andrew.j.welch@-----.--->
Date: 1/3/2008 11:28:00 AM
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


transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent