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] SML: Second Try

[ Lists Home | Date Index | Thread Index ]

One might respect it without having to marry it.

Most of what we are saying is Spy Vs Spy:  does 
the core mean the functions all systems use (so we 
are down to elements) or the basic set of services 
most people use most of the time?  Otherwise, we 
are just using our positions to marginalize groups 
of users.

The question of importance is, what is an XML 
processor normatively guaranteed to deliver as 
a service to a calling application? 

Rick Jeliffe made some very good points in this 
regard, specifically, that we may need to reclassify 
processors and document types (not DTDs, the headless 
types).  

Still, at the bottom of it all is as I said 
way back when in another thread:  the real issue 
here is what is an XML processor?  Is there one 
or many?  Does the spec have to spec only one 
or many because that is how profiles will be 
instantiated?  Should services be declared 
as profiles and each gets it's own conforming 
processor, or should we have one processor 
which can be configured for the services, 
or both?  Is it syntax based or infoset based?

Never trust a sound engineer who tells you he 
can fix it in the mix until he shows you he 
can.

len

From: Mike Champion [mailto:mc@xegesis.org]

On Mon, 10 Feb 2003 10:50:19 -0600, Bullard, Claude L (Len) 
<clbullar@ingr.com> wrote:


> The rest of what you are saying is more of the same:  fear of the wild. 
> That is, if we don't make an official subset, subsets will grow willy- 
> nilly.

Well, yeah. More or less.  See below.

>
> So?  Are we here to protect a "brand name" or to ensure that XML 1.0, 
> 1.1, are inclusive?

I guess I'm suggesting that XML not go the way of SQL, which (AFAIK from 
the very interesting XML databases town hall at XML 2002) seemed to value 
inclusiveness at the expense of coherence and interoperability.  It's much 
easier to add features to a "standard" knowing that they won't be 
universally implemented than to refactor out the core stuff that really is 
universal from the peripheral stuff that is quasi-proprietary (in the case 
of SQL) or useful only to specific subgroups (e.g. notations, parameter 
entities) or just very problematic in practice (default attribute values 
come to mind).

Inclusiveness is politically easy, but saps the real value of 
standardization. I want the core stndard to be the intersection of things 
that are actually supported and actually work, not the union of all the 
things that different people want to use.  The intersection of "SOAP 
practice" and "Docbook practice" is a subset of "XML 1.x" and I think it 
deserves a recognized identity, and some respect :-)
The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl>




 

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

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