[
Lists Home |
Date Index |
Thread Index
]
Bob,
I'd like to suggest another possible approach to this. One of your
statements in schemaStages.html is:
"Anyone who came to XML from an electronic publishing background
knows that the second option [Just keep them as separate schemas and
edit the appropriate ones when necessary.] is also unacceptable,
because it's too prone to error. As with the documents themselves,
the best way to create multiple related ones reliably and repeatably
is to create a master one and generate the others from it. "
Of course that is true if the job is done manually. But even in your
extraction process there is room for error - how do you check that
the successive stages are consistent, for example? You at least need
to check what the differences are between successive stages (I have
done this with DeltaXML and will post the results on our web site at
http://www.deltaxml.com/schema-pipeline/)
If it is possible to handle the edits/changes in an automated way,
then the second option approach is worth considering. One reason for
this is simply the case where the original schema, public.xsd, is not
your own one so you do not control it. In this case it is difficult
to add all the variations to it because someone else may change the
original schema.
We presented a paper on a related subject at XML Europe 2002. The
problem is how to update the derivations when the original changes,
and this is a 3-way merge problem. In other words, take the changes
to the original and the changes made to the derivation and merge
these together. If you can identify conflicts here then you can
always tell when there is a problem. The paper is at
http://www.deltaxml.com/pdf/merging-xml-files.pdf
Probably better to go off-line for more detailed discussions of this.
But I think there are some interesting possibilities for Schema
management if the 3-way merge can be done reliably - not only does it
help in your method when the original is not in your control, but it
allows variations to be held as standard schemas also, but managed
properly.
Robin
At 10:15 am -0400 6/6/02, DuCharme, Bob (LNG) wrote:
>It's reasonable to assume that a document moving through a pipeline of
>processes will conform to a slightly different schema after each stage. For
>example, a checkIn date-time stamp attribute may not be in the arriving
>document, but process two may require that it's in process one's output.
>
>How do you manage this collection of what are essentially variations on the
>same schema? I have a more detailed statement of the problem and a proposal
>for a solution at http://www.snee.com/xml/schemaStages.html. The problem and
>solution apply equally to W3C and RELAX NG schemas.
>
>I'd like to hear any comments and suggestions. For example, my examples are
>pretty simple; can anyone think of a reason that it might not scale well?
>
>thanks,
>
>Bob DuCharme www.snee.com/bob <bob@
>snee.com> "The elements be kind to thee, and make thy
>spirits all of comfort!" Anthony and Cleopatra, III ii
>
>-----------------------------------------------------------------
>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>
--
-- -----------------------------------------------------------------
Robin La Fontaine, Director, Monsell EDM Ltd
DeltaXML: "Change control for XML in XML"
Tel: +44 1684 592 144 Fax: +44 1684 594 504
Email: robin.lafontaine@deltaxml.com http://www.deltaxml.com
|
