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

RE: Interesting pair of comments (was Re: Schema Exp

• To: "Michael Champion" <michaelc.champion@g...>,<xml-dev@l...>
• Subject: RE: Interesting pair of comments (was Re: Schema Experience Workshop minutes online)
• From: "Michael Rys" <mrys@m...>
• Date: Thu, 14 Jul 2005 22:13:25 -0700
• Thread-index: AcWIsBdnTotjyNz0TwOMP2fkDbKjRwAS66Sw
• Thread-topic: Interesting pair of comments (was Re: Schema Experience Workshop minutes online)

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

Best regards
Michael 

> -----Original Message-----
> From: Michael Champion [mailto:michaelc.champion@g...] 
> Sent: Thursday, July 14, 2005 1:07 PM
> To: xml-dev@l...
> Subject: Re:  Interesting pair of comments (was Re: 
>  Schema Experience Workshop minutes online)
> 
> On 7/14/05, Elliotte Harold <elharo@m...> 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>
> 
> 

• Follow-Ups:
  • Re: xsi:nil is a wart (was Interesting pair of comments)
    • From: Paul Downey <paul.downey@w...>

• Prev by Date: RE: XSLT processor internals (was RE: Another XML parsing idea?)
• Next by Date: Mixed content in data-binding (Was: Re: Interesting pair of comments (was: ...))
• Previous by thread: RE: Interesting pair of comments (was Re: Schema Experience Workshop minutes online)
• Next by thread: Re: xsi:nil is a wart (was Interesting pair of comments)
• Index(es):
  • Date
  • Thread