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] PSVI formalization

[ Lists Home | Date Index | Thread Index ]

Well, the issue we are discussing is not so much whether or not we need
another schema language as whether we need *any* schema language.

If you're talking about defining standard vocabularies or "core components"
then I agree, that's a more pertinent question. Without that, none of the
web services or semantic web business is going to fly.

Matt

> -----Original Message-----
> From: Sebastian Schnitzenbaumer [mailto:schnitz@mozquito.com]
> Sent: Thursday, May 09, 2002 7:39 PM
> To: Matthew Gertner; Simon St.Laurent; xml-dev@lists.xml.org
> Subject: Re: [xml-dev] PSVI formalization
> 
> 
> Isn't the issue, instead of whether or not we need another Schema
> language, how do those schema languages interact when defining
> semantic modules that can be re-mapped into different bigger 
> markup languages, to limit the space of N^N by using atomic
> language modules instead just tags and attributes as the smallest
> unit of semantics?
>  
> - Sebastian
>  
> 
> 	-----Ursprüngliche Nachricht----- 
> 	Von: Matthew Gertner 
> 	Gesendet: Do 09.05.2002 18:35 
> 	An: 'Simon St.Laurent'; xml-dev@lists.xml.org 
> 	Cc: 
> 	Betreff: RE: [xml-dev] PSVI formalization
> 	
> 	
> 
> 	Simon,
> 	
> 	Cool, I was about to respond to your other post, but this is a
> much clearer
> 	formulation of the issue. Your initial premise is exactly right:
> what gets
> 	developers excited about XML is the prospect of schema-enabling
> it.
> 	Certainly that's true for me (your humble PSVI poster boy), and
> you're also
> 	right that I don't like CDATA, NOTATIONs and the like.
> 	
> 	I think where you are missing the boat is the assertion that
> somehow there
> 	could be some alternative representation of the PSVI that
> wouldn't be XML
> 	but would satisfy all the gearheads out there. Frankly this is a
> crazy idea.
> 	It took decades for something like XML to appear, and it's a
> huge boon. We
> 	are developing software right now that uses XML along with
> schema (having
> 	created our own version of the PSVI two years ago), and we also
> use XML
> 	parsers, XML editors, XPath, XSLT and a whole slew of other XML
> technologies
> 	and tools. Why on earth would we reinvent the wheel when XML
> works for us!?
> 	Just to preserve the "purity" of the language for the benefit of
> some markup
> 	Luddites?
> 	
> 	Someone on XML-Dev recently hit the nail on the head when they
> talked about
> 	the N^N complexity of XML integration. The only solution is to
> have commonly
> 	agreed-upon semantics for the documents, as someone else pointed
> out. The
> 	most basic semantics relating to structural and datatyping
> constraints are
> 	contained in a schema, and already make a lot of generic
> processing
> 	possible. Without this, you really can't do anything useful with
> an XML
> 	document without writing specific code, and the whole
> XML-on-the-web vision
> 	falls apart.
> 	
> 	I simply can't get away from the suspicion that your objection
> lies more in
> 	the specific instantiation of XML Schema, PSVI, XPath, XQuery,
> etc. rather
> 	than the underlying concepts. If you're such as schema skeptic,
> why did you
> 	waste all of that time with DDML? The idea of well-formed vs.
> valid
> 	documents has been around since the genesis of XML, and I don't
> remember
> 	anyone getting upset about it until we started being faced with
> an array of
> 	200-page specs that no one can understand. I would submit that:
> 	
> 	1) You are upset to see a 35-page spec turn into a 160-page spec
> with
> 	assorted dependencies in other huge specs (XPath), and this is
> 	understandable. The notion of strong typing in XPath doesn't
> seem so
> 	horrible to me, but the bloat of the spec does. In other words,
> the W3C is
> 	increasingly unable to produce simple specs.
> 	
> 	2) You are upset because it is harder and harder to divorce
> well-formed
> 	documents from valid documents. In other words, the W3C is
> increasingly
> 	unable to produce layered specs.
> 	
> 	I can't imagine an objection to the notion that XML can be
> associated with a
> 	schema, and when it is it becomes a valid document and the
> behavior of
> 	certain associated specs is extended accordingly. For example,
> XPath can do
> 	design-time type checking. If there is no schema, the document
> is
> 	well-formed and this "baggage" is ignored.
> 	
> 	Maybe you are being purposely provocative (I can relate, lord
> knows), but
> 	the idea that XML+schema is somehow no longer in the spirit of
> XML is
> 	absurd.
> 	
> 	Matt
> 	
> 	> -----Original Message-----
> 	> From: Simon St.Laurent [mailto:simonstl@simonstl.com]
> 	> Sent: Thursday, May 09, 2002 5:15 PM
> 	> To: xml-dev@lists.xml.org
> 	> Subject: [xml-dev] PSVI formalization
> 	>
> 	>
> 	> Recent discussions here about XQuery, XPath 2.0, and their
> knotted
> 	> relationships with W3C XML Schema have made me think a fair
> 	> amount about
> 	> the relationship between XML and W3C XML Schema, particularly
> the
> 	> Post-Schema Validation Infoset (PSVI), more deeply. 
> 	>
> 	> There were a bunch of presentations last year about how XML +
> 	> XSD -> XML
> 	> 2.0, something I found merely annoying then but which makes
> more sense
> 	> now.  The community that craves these features is poorly
> 	> served in many
> 	> ways by XML 1.0, with its text orientation, structures that
> 	> can be loose
> 	> to the edge of complete unpredictability, and a
> human-readability
> 	> requirement that is incredibly verbose but useful in many
> 	> cases only for
> 	> debugging stages.
> 	>
> 	> XML 1.0 is now more and more buried under layers of other
> processing,
> 	> and the common foundation for W3C work moving forward appears
> 	> to be the
> 	> PSVI - or at least an enormous amount of effort is going into
> 	> integrating the PSVI with a large number of projects, and it
> 	> seems that
> 	> most of the vendor and programmer excitement these days is
> focused on
> 	> the PSVI, not the brutish markup that lurks underneath.
> 	>
> 	> The PSVI seems to be what programmers and database folks want.
> It
> 	> offers strongly typed and highly structured information,
> already
> 	> guaranteed to conform to their expectations.  It has the same
> flexible
> 	> named hierarchies that XML offers, with none of the messy
> 	> concerns about
> 	> character encodings, CDATA sections, or the limitations of
> text for
> 	> storing binary information.
> 	>
> 	> At the same time, the PSVI is pretty difficult to express in
> XML.
> 	> Layers of type information can make it complex to pin down how
> best to
> 	> describe a particular piece of information.  Object-oriented
> 	> development
> 	> manages that every day, but doesn't have to express the whole
> 	> hierarchy
> 	> for every piece of information in a flat representation.
> Given recent
> 	> discussions of synthetic PSVIs, it's not always clear that
> 	> XML+schema->PSVI.
> 	>
> 	> I'm concluding from all of that that XML is not a good
> foundation for
> 	> the kinds of information developers want from the PSVI, and
> that
> 	> retrofitting XML to carry that information is perhaps the
> 	> root cause of
> 	> the complexity explosion we're seeing in W3C XML Schema and
> 	> specifications which build on it.  It seems to me that it
> 	> might be wiser
> 	> to use the PSVI directly for more abstract information
> modeling rather
> 	> than expecting XML representations to carry the load.
> 	>
> 	> So where does this take us?  Developers who want to work with
> the PSVI
> 	> should work with the PSVI, and not worry about XML.  The kind
> of
> 	> interoperability the PSVI is designed to provide is very
> 	> different from
> 	> the kind of interoperability that XML provides - a perfectly
> 	> reasonable
> 	> conclusion given the different situations leading to the
> creation of
> 	> their respective specifications.
> 	>
> 	> Beyond that, it seems like some easily-exchanged
> representation of the
> 	> PSVI is in order.  XML works, sort of, but it seems pretty
> 	> obvious that
> 	> there are better approaches to representing information if
> 	> you have all
> 	> the information the PSVI provides rather than a simple "all is
> text"
> 	> approach.  This could easily be a binary format, though text
> 	> might also
> 	> be an option.
> 	>
> 	> XML has done a wonderful job of convincing the world that it
> 	> is possible
> 	> to agree on base formats for some kinds of information, and
> 	> that generic
> 	> tools (parsers, editors, etc.) can be useful for a wide
> variety of
> 	> specific problems.  It seems reasonable to suggest that the
> lesson of
> 	> XML is not "everyone must use angle brackets and text" but
> rather that
> 	> "shared information formats are really useful when supported
> by a
> 	> reasonable set of tools".
> 	>
> 	> Given the immense bias in current XML work at the W3C toward
> 	> support for
> 	> the PSVI, it seems like it might well be time to find an
> appropriate
> 	> means of expression for the PSVI.  Conversions from strongly
> 	> typed PSVI
> 	> to loosely typed XML should be trivial, while XML to PSVI
> should only
> 	> require a W3C XML Schema (or other PSVI generator) to provide
> the
> 	> necessary information.
> 	>
> 	> PSVI processors could use or extend existing XML
> infrastructures,
> 	> replacing only the bottom layer - the parser - and possibly
> developing
> 	> its own structures for the layers above.  I suspect that
> 	> taking the PSVI
> 	> to its fullest potential is going to involve a lot more work
> 	> than taking
> 	> untyped markup to its fullest potential.  It's simply a larger
> set of
> 	> problems.
> 	>
> 	> A binary PSVI format could sure make XML-RPC (PSVI-RPC?)
> 	> messages a lot
> 	> smaller.  All it takes is a spec, some free parsers, and some
> tools.
> 	> Maybe someday programmers will look back on XML as the
> bootstrap phase
> 	> of the PSVI, while the occasional markup geek still pokes
> around CDATA
> 	> sections.
> 	>
> 	> --
> 	> Simon St.Laurent
> 	> Ring around the content, a pocket full of brackets
> 	> Errors, errors, all fall down!
> 	> http://simonstl.com
> 	>
> 	>
> 	>
> -----------------------------------------------------------------
> 	> 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://lists.xml.org/ob/adm.pl>
> 	>
> 	
> 	
> -----------------------------------------------------------------
> 	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://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