OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



From: W. E. Perry <wperry@fiduciary.com>

>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