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

Re: Personal reply to Edd Dumbill's XML Hack Article wrt W3C XML Schema

  • From: Rick Jelliffe <ricko@a...>
  • To: XML DEV <xml-dev@l...>
  • Date: Tue, 13 Mar 2001 10:01:29 +0800

xml schema best practise
From: W. E. Perry <wperry@f...>

>The point here is that no party--not
>the sender, and none of the downstream receivers--has the standing to fix
the
>semantics of the elements transmitted in the XML document.

I am not sure that your mode of processing is so irreconcilable with XML
Schemas.

For SGML processing, it used to be common practise (when using systems
flexible enough) to tailor the DTD for each stage in a pipeline.

In XML Schemas, you can derive a new schema from a base schema (in
compatible ways only.)  This suggests that it may be best practise for
public schemas to be as open as possible (a point Roger Costello has made
for othe reasons), to allow sender and recipient to have custom schemas as
appropriate.

For schema changes that do not fit into that mould, a recipient is free to
create their own completely independent schema for a namespace.  Of course,
it would be impolite and confusing to release this to the public, and you
would have to make sure your tools use an OASIS CATALOG in preference to the
schemaLocation hint or retrieval from the Namespace URI (e.g., hopefully
from a RDDL directory).

If you were worried about managability of radically different schemas for
different namespaces, you could create a simple XSLT (or OmniMark or Perl
etc) transformation to remap the namespaces. (That might be a good candidate
for a SAX processor: perhaps Dave Megginson's XAF can already do the
equivalent using architectural forms anyway!)

Note, for the idea of just decorating the instance with type information
between processes, there is the DT4DTD note at www.w3.org/TR by Lee Buck,
Charles Goldfarb and Paul Prescod.

All that being said, the theoretical point you make is good: I would
rephrase it and limit it to say that sometimes we want to process data
according to its storage type, sometimes we want to process data according
to its facets' values, sometimes we want to process data according to its
lexical or value space, sometimes as text, and sometimes we want to process
data as symbols.

DTDs only gave us enough information to process data as text or as symbols.
This is enough for a lot of applications, because the data comes or goes to
specialist applications that allow processing by other mechanism.  From this
view, XML Schemas is not much help for existing symbolic-processing uses,
but maore targetted at extending the reach of where data can be considered
"XML" in some way...it allows us to think of "XML databases" and so on.

Cheers
Rick Jelliffe


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.