Re: [xml-dev] Conditional xml Schema

["Joe Schaffner" <schaffner.joe@gmail.com>]

Field Validation

Ok, I get it. The operating environment looks something like this:

$ xsd my.xsd < my.xml | valid my.valid | xsl my.xsl | browser

'xsd' validates the instance document against the schema my.xsd and
produces a copy of the input document if it is ok, otherwise it throws
an exception and the program abends, closing the pipe.

'valid' does the data i.e. field validation. It could be rule-based,
for example:

<fraction>
 <numerator>1</numerator>
 <denominator>0</denominator>
</fraction>

would need a rule something like this:

DENOMINATOR EQ. 0 ? THROW DIVIDE_BY_ZERO

The output of the validator would also be a copy of the instance
documtent, which would be stdin for the stylesheet processor 'xsd'
which would convert the xml to html, which is fed into the browser.
(BTW, I haven't found a browser that actually works like this. They
don't use stdin. Usually you have to create a temp file which contains
the html)

So, given this standard, canonical UNIX-style processing model my question is:

If the various processing programs are not distributed as stand-alone
filters, they must be distributed using some kind of component
technology. I am interested in knowing more about the component
technologies. Which ones are used.

1) Is the API a Netscape style "plug-in"
2) A Microsoft style "add-on" i.e. an ActiveX control
3) A more flexible approach, like CORBA
4) A Java technology, like Beans.

Distributed as components, these "programs" could be easily wrapped in
a command-line filter which reads stdio and could be used in a
traditional pipe.

So, I should be able to developeXMLapplications using a standard
XML-compatable browser and a text editor, no additional programs would
be needed, nothing more to install, but I need to get at the
components.

Are the componets distributed as "wrapped" filters?

Any explainations/comments would be greatly appreciated.

You guys are great.

Thanks,

Joe
http://modern-greek-verbs.tripod.com/agv/
================================

On 6/13/06, Erik Wright <erik.wright@radialpoint.com> wrote:
> In the case of <choice/>, you will specify a choice of either an element named "Orange" of type "OrangeType", or an element named "Apple" of "AppleType".
>
> An instance document will have one or the other (or multiple elements, each of which is either Apple or Orange, if you use minOccurs+maxOccurs).
>
> Schema validation is easy in this case. If the element is named Apple, the AppleType schema rules apply. If it is named Orange, the OrangeType rules apply.
>
> In the case of using polymorphism, you will define an element named "Fruit" of type "FruitType". So how does the document consumer know if it is an instance of AppleType or OrangeType? You must specify the type in the XML instance document:
>
> <Fruit xsi:type="AppleType">
>        ...
> </Fruit>
>
> Regarding your "Where does XML run" question... An application that consumes XML documents MAY validate the documents using a schema. In that case, the application must get the XML instance document, get the XML schema document, and invoke a schema validation engine that compares the instance to the schema.
>
> In Java, for example, you can create an XMLParser, enable the XSD schema validation option, and when you load any document that specifies an xml schema (using the optional xsi:schemaLocation attribute) the schema will automatically be retrieved to validate the doc. Parsing will fail if the validation fails. In the most recent version of the Java XML APIs there is a direct way to construct a validator from a schema. You can then pass as many documents as you want (with no custom markup) through the validator.
>
> Another way XSD is used is in defining web service contracts (as part of a web service desctription, or WSDL, file). In the simplest case, the XSD may be used by your web service engine to automatically build a Java/C++ object model that maps to the XSD objects used by your service. When a SOAP request is received, it is validated against the XSD and then automatically deserialized into the Java/C++ objects, which are then given to your web service implementation. When your service implementation returns its results (as objects) the web service engine will convert them back into XML that matches the XSD and return that to the client in a SOAP response.
>
> -Erik
>
> > -----Original Message-----
> > From: Joe Schaffner [mailto:schaffner.joe@gmail.com]
> > Sent: June 12, 2006 3:07 PM
> > To: Erik Wright
> > Cc: Ramkumar Menon; Jirka Kosek; Jagdishwar B; xml-dev@lists.xml.org
> > Subject: Re: [xml-dev] Conditional xml Schema
> >
> > Thanks Erik,
> >
> > Yours looks like the canonical approach, like C++ classes, or
> > C unions, but I'll have to get used to idea of cross-field validation.
> > It sounds strange to me. Just a quick glance online seemed to
> > indicate this was some sort of field validation, where you
> > want to be sure that elememt content comes from some
> > well-defined domain.
> >
> > Since I am not familiar with the procedural semantics of XML,
> > I do not know how someone would validate user-defined types.
> > It looks like XML can contain procedures written in Java, but
> > now I'm getting confused by the operating environments. Just
> > where does the XML run?
> >
> > Joe
> > http://modern-greek-verbs.tripod.com/agv/
> >
> > On 6/12/06, Erik Wright <erik.wright@radialpoint.com> wrote:
> > > XSD supports this type of behaviour in various ways.
> > >
> > > One way is to define a base type (fruit) and extend it with
> > other types (apple, orange). Then when defining the container
> > element, you would define it as having children of type
> > fruit. The instance document could incorporate either type.
> > >
> > > Another way is to use the choice element in your schema. It
> > matches one of a specific list of types. To have several
> > fruit (each of which might be apple or orange) you can use
> > the minOccurs and maxOccurs attributes on the choice.
> > >
> > > -Erik
> > >
> > > > -----Original Message-----
> > > > From: Ramkumar Menon [mailto:ramkumar.menon@gmail.com]
> > > > Sent: June 11, 2006 2:10 PM
> > > > To: Joe Schaffner
> > > > Cc: Jirka Kosek; Jagdishwar B; xml-dev@lists.xml.org
> > > > Subject: Re: [xml-dev] Conditional xml Schema
> > > >
> > > > Cross field constraints are better off described thru rule based
> > > > validation languages like schematron. Use this in
> > conjunction with
> > > > the XSD to enable cross field validation on fields.
> > > >
> > > > <pattern name="checkMangoOrApple">
> > > >   <rule context="Fruit">
> > > >      <assert test="@myAttr='Apple' and elementApple1>If myAttr is
> > > > apple, elementApple1 should be present"/>
> > > >      <assert test="@myAttr='Mango' and elementMango1>If myAttr is
> > > > mango, elementMango1 should be present"/>
> > > >   </rule>
> > > > </pattern>
> > > >
> > > >
> > > >
> > > > On 6/11/06, Joe Schaffner <schaffner.joe@gmail.com> wrote:
> > > > > Why don't you define a Mango element and an Apple element,
> > > > each with
> > > > > their own structure? I'll bet there is even a way to define a
> > > > > Fruit element, then derive an Apple and a Mango from Fruit. Then
> > > > you would
> > > > > instantiate either type of fruit, Apple or Mango, and get
> > > > the proper
> > > > > structure.
> > > > > Joe
> > > > > http://modern-greek-verbs.tripod.com/agv/
> > > > > PS
> > > > > It looks like you are trying to use the attribute to name
> > > > the element
> > > > > type, which would be unnecessary, and it would surprise me
> > > > if xsd --
> > > > > or any schema definition language -- would attribute class
> > > > semantics
> > > > > to the arrtibutes you create arbitrarily. You are trying to
> > > > place your
> > > > > metadata in the data domain.
> > > > >
> > > > > On 6/11/06, Jirka Kosek <jirka@kosek.cz> wrote:
> > > > > > Jagdishwar B wrote:
> > > > > >
> > > > > > > Is it possible to define the xml schema (xsd)
> > > > conditionally based
> > > > > > > on certain values.
> > > > > >
> > > > > > No. You have to use RELAX NG or Schematron to express
> > > > such constraints.
> > > > > >
> > > > > > --
> > > > > >
> > ------------------------------------------------------------------
> > > > > >   Jirka Kosek     e-mail: jirka@kosek.cz
> > http://www.kosek.cz
> > > > > >
> > ------------------------------------------------------------------
> > > > > >   Profesionální školení a poradenství v oblasti
> > technologií XML.
> > > > > >      Podívejte se na náš nově spuštěný web http://DocBook.cz
> > > > > >        Podrobný přehled školení http://xmlguru.cz/skoleni/
> > > > > >
> > ------------------------------------------------------------------
> > > > > >                    Nejbližší termíny školení:
> > > > > >        ** DocBook 15.-17.5.2006 ** XSL-FO 12.-13.6.2006 **
> > > > > >     ** XSLT 23.-26.10.2006 ** XML schémata 13.-15.11.2006 **
> > > > > >
> > ------------------------------------------------------------------
> > > > > >   http://xmlguru.cz    Blog mostly about XML for
> > English readers
> > > > > >
> > ----------------------------------------------------------------
> > > > > > --
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Shift to the left, shift to the right!
> > > > Pop up, push down, byte, byte, byte!
> > > >
> > > > -Ramkumar Menon
> > > >  A typical Macroprocessor
> > > >
> > > >
> > >
> >
> >
>