OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] Interesting pair of comments (was Re: [xml-dev] Schema Exp

[ Lists Home | Date Index | Thread Index ]
  • To: "Michael Champion" <michaelc.champion@gmail.com>,<xml-dev@lists.xml.org>
  • Subject: RE: [xml-dev] Interesting pair of comments (was Re: [xml-dev] Schema Experience Workshop minutes online)
  • From: "Michael Rys" <mrys@microsoft.com>
  • Date: Thu, 14 Jul 2005 22:13:25 -0700
  • Thread-index: AcWIsBdnTotjyNz0TwOMP2fkDbKjRwAS66Sw
  • Thread-topic: [xml-dev] Interesting pair of comments (was Re: [xml-dev] Schema Experience Workshop minutes online)

Xsi:nil is not central to data apps. It is an ugly wart...

Best regards

> -----Original Message-----
> From: Michael Champion [mailto:michaelc.champion@gmail.com] 
> Sent: Thursday, July 14, 2005 1:07 PM
> To: xml-dev@lists.xml.org
> Subject: Re: [xml-dev] Interesting pair of comments (was Re: 
> [xml-dev] Schema Experience Workshop minutes online)
> On 7/14/05, Elliotte Harold <elharo@metalab.unc.edu> wrote:
> > Paul Downey wrote:
> > 
> > > Agreed, but so are processing instructions and DTDs, and 
> yet some  domains
> > > choose to exclude them, e.g.:
> > >
> > > http://www.ws-i.org/Profiles/BasicProfile-1.1-2004-08
> > > -24.html#Disallowed_Constructs
> > >
> > 
> > And I'm on record as saying that's a major mistake. But again you're
> > confusing different issues. restricting the syntactic 
> constructs allowed
> > in a particular application has nothing to do with what 
> constraints a
> > schema language can express on the structures of documents.
> > 
> I think this is all just proving Paul Downney's point that "my 20 is
> your 80" and vice versa.  Mixed content, entites, PIs, etc. are
> undeniably central to document apps, but an annoyance to data-centric
> apps.  Types, the PSVI, and nil are central to data apps but an
> annoyance to pure document folks.  But that doesn't mean we can all
> just go our separate ways: there is a huge middle ground (e.g. most
> InfoPath documents) that have features from both worlds, because real
> business documents have both semi-structured text and strongly typed
> data in them.
> That's why I agree  that any profiles or XML or XSD that are optimized
> for one domain's requirements should not be standardized by an
> infrastructure-level organization such as W3C. Better to have
> processors optimized for some domain-specific profile but still
> capable of gracefully (if not efficiently or conveniently) handling
> anything corresponding to the core specs.
> The implicit SOAP profile with no DTDs or PIs is an interesting case
> ... I believe that's a reasonable profile for that rather broad domain
> given the truly nasty security and efficiency implications of entity
> expansion, but obviously it's something about which reasonable people
> disagree.
> Rick presented some very interesting ideas for how XSD could be
> modularized.  I (personally, day job hat is in the closet) really
> think these should be seriously explored, but I don't think a
> standards organization is the place to explore them.  Academia? 
> Vertical industry associations?  Ad-hoc efforts of the sort that
> created SAX?  *If* some really clean and compelling results can be
> demonstrated, then it would be time to try to get them standardized in
> "XSD 2.0" or whatever.
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
> The list archives are at http://lists.xml.org/archives/xml-dev/
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>


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

Copyright 2001 XML.org. This site is hosted by OASIS