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


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] XML Schema views - are they possible?

[ Lists Home | Date Index | Thread Index ]


This is another problem (yeah - this gets boring after a while!) that 
CAM solves explicitly through the use of context.

So you would have something like - $submission_type  as the context - 
with Initial_Submission, Normal_Submit, Exceptional_Submit  as values - 
and then the CAM processor can adjudicate which combo of structure 
components is required / optional.

You have several ways you can slice-n-dice this.  Either separate 
structures with a choice switch, or sub-structures with <as:include> s,  
or one structure and then conditional inclusion / exclusion, or combo of 
all three approaches!  Depends on what 'effect' you want to achieve - 
layering, objects, or import style function.  Also depends on how opaque 
you want to make this for people looking at your CAM templates (radical 
concept, eh?  We expect people to be able to read these and understand 
them as plain old markup).

Cheers, DW.

DuCharme, Bob (LNG-CHO) wrote:

>>Did you address the problem of having multiple layers of abstraction and
>>the use of global elements that forces one to use namespaces?  GJXDM
>>is wrestling with this one.
> My basic use case was a workflow in which an element or attribute that 
> can't possibly exist at step 1 (e.g. an "arrived" date-time stamp on 
> data sent from a supplier) is required at step 1 + x. We don't want to 
> just declare it as being optional up and down the line; we want a 
> validation process after step x to flag files missing this data.
> The approach is to declare everything you'll ever need and identify 
> where you need it in the central mother schema and then extract what 
> you need for each step using the stylesheet. It should work in some 
> cases in which the "views" do not necessarily describe the states of 
> data in a sequential process, but that was the problem I was focused 
> on. (We've got a lot of XML data moving through a lot of processes 
> here.) I didn't try pushing it into a more generalized version of a 
> "view" implementation, so, I'm not sure about dealing with the 
> multiple layers of abstraction.
> Bob


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS