Altova Mailing List Archives

Re: [xml-dev] Interoperability [long]

From: Eddie Robertsson <eddie@-------.---.-->
To: Tim Bray <tbray@----------.--->
Date: 11/16/2001 1:15:00 AM

> Every parser I've ever seen supports 8859-1.  Is there a
> single counterexample?  But <snicker> that doesn't help you
> though, because I can always put &#x20ac; (Euro) in my 8859-1
> text.  BTW Sean, how do you do Euros?  SGML had SDATA
> entities, but they had poor interoperability and flaky
> product support.
> Here's one area where SGML (kind of) wins.  You could in
> theory limit the charset to 8859-1 in the SGML declaration.
> Mind you, I never heard of anyone ever doing this on a
> production basis... toolset problems?
> I guess the modern schema datatypes kind of allow you
> to do this via the regexp tools?

Yes, If I understand the datatype spec correctly you can do either:

<xs:simpleType name="ISO8859_1">
  <xs:restriction base="xs:string">
    <xs:pattern value="\p{BasicLatin}+"/>
    <xs:pattern value="\p{Latin-1Supplement}+"/>


<xs:simpleType name="ISO8859_1">
  <xs:restriction base="xs:string">
    <xs:pattern value="[&#0000-&#00FF]+"/>

for one or more characters in ISO8859-1. See [1]



> >Oh, BTW, Opera and lots of other tools out there that
> >call themselves XML compliant, don't do Unicode. Worse, they
> >silently don't do Unicode. You find these things out
> >the hard way.
> Then they're NOT XML TOOLS and this is NOT XML's FAULT.
> BTW, the browsers actually do a pretty good job in my
> experience.  Hey Sean, let's name some names and put
> some pressure on the vendors.
> >Call me a fuddy-duddy but simple stuff like this
> >was simpler with the *complex* SGML standard
> >than it is with the *simple* XML standard.
> I'll certainly buy into the premise that SGML tools
> tend to be heavily authoring-focused.  One reason is
> that in large part, all that ever happened with SGML
> was you authored it and then you printed it.  The great
> virtue was you could still print it 10 years later...
> try that with MS Office.
> >To return to the original spark of this, I believe that a significant
> >part of the problem is that XML's definition is just syntax
> >and compliance with the syntax doesn't tell you a lot
> >when it comes to tying components together into complete
> >systems.
> You've pointed useful fingers at some gaps in our tool
> repertoire, particularly in the authoring-support and
> content-management spaces.  It's not obvious to me that
> a focus on structure rather than syntax would really
> be that important in fixing these problems.
> And I stand by my claim, based only on my personal
> experience, that in heterogeneous distributed environments,
> it's easier to agree on syntax than on data structures.
> And way more robust.  Clearly there are those who have
> different experiences. -Tim
> -----------------------------------------------------------------
> The xml-dev list is sponsored by <>, an
> initiative of OASIS <>
> The list archives are at
> To subscribe or unsubscribe from this list use the subscription
> manager: <>


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 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.