[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
Re: [xml-dev] Backward and forward compatible schemas ... Relax NG --> Yes... XML Schema --> No
- From: noah_mendelsohn@us.ibm.com
- To: "bryan rasmussen" <rasmussen.bryan@gmail.com>
- Date: Mon, 27 Aug 2007 09:23:08 -0400
Bryan Rasmussen writes:
> Although I like the model for handling any in XML Schema 1.1
> theoretically I think from the point of view of Data processing
> applications contra the view of Data presentation applications they
> are a minefield.
> The benefit of having to have a wrapper for any if you wanted to get
> anything useful done with it, was that you could make much simpler
> rules for how one needs to process the extension. This is useful in
> large codebases cause you can assume the chance of a mess up is
> lessened.
Yes, and if that meets your needs better, you can of course do that in
Schema 1.1 too. I do have a concern that after 50 revisions, 50 nested
<extension> elements can get clumsy, and I think you have to remember
which extension got introduced in which revision.
As to the difficulties of processing content validated with those
wildcards: we've assumed that many of the API stacks built for this
purpose will signal to applications which content was validated by
implicit wildcards, or perhaps explicit wildcards if you like -- the API
designer can deside what meets the needs of his/her customers. That way,
all the content you were "expecting" in a given level of the schema will
show up in one part of the API, and strongly typed if you like, and the
extension content that you don't really understand but are just
"tolerating" due to those wildcards will be given to you marked
differently in the API. In fact, this is the upside of the much debated
UPA contstraint: because the parse is relatively deterministic, it's
always possible to tell unambiguously what was accepted by an explicit
particle and what by a wildcard, and the answer will always be the same
for any given {schema, instance} pair. So, UPA is a tradeoff, but that's
the "helpful" side of it.
Noah
--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]