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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-core message

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


Subject: Re: The role of context in the re-usability of Core Components andBusiness Processes - OR Say What???


Bob,

It would appear that you have not yet taken a look at the document
"ebXML specifiation for the application of XML based assembly and
context rules". I think you should, as it may answer some of your
questions and concerns.

Eduardo

"Miller, Robert (GXS)" wrote:
> 
> Martin,
> 
> My comment about eliminating optional fields was a tongue-in-cheek comment
> prompted by another thread in which William Kammerer was trying to explain
> why the spreadsheet column for REQUIREMENT (Mandatory/Optional) was
> redundent to MinMaxOccurs (0.. / 1..).
> 
> I was not aware of any distinction made between 'assembly' rules and
> 'context' rules (in the spreadsheet - as you observe, such distinction is at
> least conceivable.)
> 
> I happen to have utmost confidence in the ability of industry groups to
> produce schemas that reflect their required 'assembly' rules.  But I have
> zero confidence that an algorithmic process bombarded with assembly rules
> representing a myriad of assembly contexts for a core component would
> produce the schema a given industry expected and required to meet their
> member needs.  Among other problems, how does one discern whether a given
> rule an 'assembly rule' or a 'context' rule in the realm of a specific
> industry.  There likely is interplay among the various contexts that affect
> what is an 'assembly' rule and what is a 'context' rule for any of the
> possible combinations of contexts (though of course not all possible context
> combinations are likely to occur in real life).  My argument therefore is
> that there are no 'assembly' rules, only context rules.  When an industry
> association produces a schema which omits parts of a core component, in so
> doing it acknowledges that some context rules could be applied at assembly
> time, and in so doing, the context rules associated with the omitted
> entities are gone with the omitted entities themselves.
> 
> While I support efforts to capture context information in the metadata
> associated with core components, I do not share the vision of some that this
> information will then be used to automatically generate schemas.  Instead, I
> expect that an industry group would follow much the same process it now
> follows with an X12 or UN/CEFACT 'scheam'.  It starts with the generic
> scheam and throws away the stuff it doesn't need.  In X12 and UN/CEFACT,
> some artifacts of the process (fields marked "NOT USED") remain due to
> syntax constraints. In XML, the artifacts simply disappear.
> 
> Cheers,
>          Bob Miller
> 
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org


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

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC