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 ]

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.




 

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

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