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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-cmsc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: [ubl-cmsc] The "Phase 1 context methodology" proposal


Eve,

Yes, this is definitely an idea worthy of serious discussion. A set of
contextualized schemas that have been hand-derived would also be the ideal
basis for figuring out how to automate the process in the future. I am
available any of the times you suggest except tomorrow (Friday). Earlier is
better for me, so I would prefer 4pm CET next Monday or Tuesday.

Cheers,
Matt

> -----Original Message-----
> From: Eve L. Maler [mailto:eve.maler@sun.com]
> Sent: Wednesday, June 12, 2002 4:29 AM
> To: ubl-cmsc@lists.oasis-open.org
> Subject: [ubl-cmsc] The "Phase 1 context methodology" proposal
> 
> 
> I took an action to explain the proposal that I came up with 
> for a Phase 
> 1 CM deliverable.  I'm also supposed to try to set up a CM telecon to 
> keep the discussion going.  (There were other big CM 
> developments last 
> week as well...)  Matt, s'okay with you?  If so, here are the 
> times I'm 
> free in the coming few days; please respond with your own subset of 
> these times and I would be happy to set up a phone call:
> 
> Fri 14 Jun: 7am-10am PT / 10am-1pm ET / 3-6pm UK / 4-7pm Eur
> Mon 17 Jun: 7am-10am PT / 10am-1pm ET / 3-6pm UK / 4-7pm Eur
> Tue 18 Jun: 7am-11am PT / 10am-2pm ET / 3-7pm UK / 4-8pm Eur
> Thu 20 Jun: 9am-11am PT / 12n-2pm ET  / 5-7pm UK / 6-8pm Eur
> Fri 14 Jun: 7am-10am PT / 10am-1pm ET / 3-6pm UK / 4-7pm Eur
> 
> Eventually I will have to write up the proposal properly (and 
> give it a 
> cutesie name; nothing has stuck yet :-), but I wanted to try 
> and get the 
> bare bones out there as soon as I could.  Here it is:
> 
> Summary:
> 
> . For Phase 1, do not yet enable the description of *deltas* between
>    less-contextualized and more-contextualized types and 
> schemas (context
>    rules). Instead, enable merely the *description of the actual
>    contexts* that apply to hand-derived schema modules built on top of
>    UBL.  Allow these descriptions to be "defaulted" somehow 
> for all types
>    in a schema module, for ease/economy of context value assignment.
> 
> Consequences:
> 
> . Makes contextualized schemas stay strictly compliant with XSD
>    derivation.  (And likely pushes us in this direction for future CM
>    phases...)  Allows us not to have to re-solve all the problems that
>    XSD currently solves, such as worrying about how to set 
> the namespace
>    of the constructs in the resulting contextualized schema.
> 
> . Pushes the work of generating derivations onto fairly knowledgeable
>    schemographers.  (Since there are tools and tutorials 
> extant for XSD
>    work but not yet for context rules design, this doesn't 
> seem like much
>    of a cost.)
> 
> . Will probably encourage the creation of contextualized schemas
>    overall, possibly resulting in a more confused picture of 
> what modules
>    get registered and what their relationships are to each other.
>    However, getting this input will be a real win for our 
> work on Phase
>    2.
> 
> . Will result in the context descriptors for contextualized 
> schemas and
>    for the base UBL Library modules taking exactly the same 
> form, which
>    is nice.
> 
> Work to be done:
> 
> . We need to fully solve the general problem of documenting applicable
>    contexts in order to allow hand-coders to add their context
>    descriptions to their own types.  We discussed this at some length
>    in the NDR meeting last week and made some progress.
> 
> . We need to figure out the defaulting rules of context 
> descriptors that
>    appear "globally" in the prolog of a schema module.  It must be
>    possible at any time to "compute", given a stack of schema modules,
>    the applicable context for any object class.
> 
> . We need to fully flesh out the rules for allowable 
> contextualizations,
>    much as XSD defines the rules for allowable derivations.  
> The context
>    descriptors will be metadata on types that forms a phantom context
>    hierarchy; what are the rules for context derivation?  Eduardo has
>    already proposed one about properly specializing the context value
>    hierarchy (see the NDR F2F minutes).  We will probably also need
>    rules about computing from "additive" contexts (e.g.,
>    geo="Americas+Asia") and ranges of contexts.
> 
> I would say that, if this proposal is acceptable to the fully 
> constituted CM group, we need to produce this deliverable 
> *fast* and we 
> would need to promote it in much the same way as the code list 
> recommendation, since both apply mostly to external producers and not 
> just UBL proper.
> 
> A random observation: If formal mathematical comparison of 
> XSD modules 
> were easy to do, in the fashion that RELAX NG is amenable to 
> this, then 
> heck -- the context rules themselves could possibly be 
> computed from the 
> comparison of two contextually related schema modules!
> 
> BTW, I am taking cutesie name suggestions.
> 
> 	Eve
> 
> -- 
> Eve Maler                                    +1 781 442 3190
> Sun Microsystems XML Technology Center   eve.maler @ sun.com
> 
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
> 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC