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

RE: PSVI formalization


unable to get psvi components
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@m...]
> Sent: Thursday, May 09, 2002 7:39 PM
> To: Matthew Gertner; Simon St.Laurent; xml-dev@l...
> Subject: Re:  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@l... 
> 	Cc: 
> 	Betreff: RE:  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@s...]
> 	> Sent: Thursday, May 09, 2002 5:15 PM
> 	> To: xml-dev@l...
> 	> Subject:  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>
> 	
> 	
> 
> 

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.