Re: Component-Based Schema Design

Hi Pete,

Pete Muriello wrote:
> 
> I'd like to understand more about how schema chunks would be "glued
> together" and "validate/partially validated".  I know you talked about
> "partial validation" a bit, but I wonder if you can expound on this.

Sure.  This is actually a very exciting topic.  Let's take the
pilot/bomb-target that I presented:

> EXAMPLE - EXTRACT/PROCESS THE TARGET POSITION CHUNK
> 
> A pilot is handed a floppy containing a document that contains, among
> other things, the position of a target to be bombed.  He inserts
> the floppy into his on-board computer, which has a cached copy of the
> position schema chunk.  The computer validates the position data,
> extracts it, and loads the coordinates into the ordinance.  The other
> information on the floppy is irrelevant, and couldn't be validated 
> even if desired since the pilot has no connection to a network.

Here's what an instance document might look like:

<?xml version="1.0"?>
<Mission>
    <Classification xmlns="http://www.security.gov">
        <Level>secret</Level>
        <Date>
            <Month>December</Month>
            <Day>30</Day>
            <Year>2002</Year>
        </Date>
        <ClassifyingDepartment>Zooloo</ClassifyingDepartment>
        <Expiration>
            <Month>January</Month>
            <Day>01</Day>
            <Year>2003</Year>
        </Expiration>
    </Classification>
    <Target>
        <Position xmlns="http://www.location.org">
            <lat>+34.56</lat>
            </lon>-114.67</lon>
            <msrmt_accuracy units="meters">0.2</msrmt_accuracy>
            <id>tango</id>
        </Position>
    </Target>
</Mission>

Notice that this instance document contains two "data chunks" ... the
Classification data chunk and the Position data chunk, and each belong
to a different namespace.  These data chunks are the important stuff.
The other elements (Mission, Target) are simply "glue" elements.  

Notice that there is no schemaLocation attribute.  Consequently, at "run
time" (validation time) you must tell the schema validator what schema
should be used to validate the Classification data chunk, and what
schema should be used to validate the Position data chunk.  In my
example, the pilot is only interested in the Position data chunk, so we
will only supply this pair of values:

    {http://www.location.org, position.xsd}

That is, "hey schema validator, in this instance document I want you to
validate the elements that belong to the http://www.location.org
namespace using the position.xsd schema".  Thus, just the Position chunk
is validated and the rest is ignored.  That's exactly what the pilot
wants.  For more info on how to do this see my tutorial [1]
 
> One concern I have with regard to the "no dependencies" part of the
> definition, is that people would find it hard to agree on the 
> definition of the chunks and we'd all wind up using our own versions 
> of otherwise similar "chunks".  This would be fine if your goal was to 
> make it easier to use schemas within an organization, but you state 
> that your goals are interoperability and broad adoption.

Well, other communities have done it, so I believe that we can do it as
well.  For example, in the graphics community nobody does the low-level
graphics stuff anymore.  Everyone uses graphics components.

[1] http://www.xfront.com

Received on Monday, 30 December 2002 12:21:38 UTC