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: where the qualifiers went...

Hi there,
               I guess in UML the qualifiers maybe represented as
contraints - probably <xsd:restriction> in XML Schemas

Cheers, Phil
----- Original Message -----
From: "Miller, Robert (GXS)" <Robert.Miller@gxs.ge.com>
To: "ebXML Core" <ebxml-core@lists.ebxml.org>
Sent: Thursday, May 31, 2001 9:07 PM
Subject: RE: where the qualifiers went...

> Good People,
> The hanging question is when are we going to have a sound UML model for
> defining Core Components?
> It is difficult (and I believe counter-productive) to 'define' a core
> component (e.g., 'amount') when we haven't first defined and agreed upon a
> UML model.
> I would hope that the model that is developed would not support as a Core
> Component 'totalAmountInDollars' or 'shipToParty'.  I would want the UML
> model to support 'Amount' in an 'atomic' manner such that the properties
> required to produce a 'whole/usable' semantic entity were an integral part
> of the definition of Amount.  For 'amount', that would include a semantic
> definition (or to my preference, a pointer to a body of XML containing the
> definition in some standardized form); a data type (and by association to
> the data type class, a set of properties linked to that class, such as
> limits); a currency designation (or a means to derive same from elsewhere
> the document or schema); a semantic constraint (e.g., some (super/)subset
> the ASC X12 DE 522 Amount Qualifier Code list.  NOTE: The ASC X12 Amount
> Qualifier Code List is incomplete, because many segments which contain an
> 'Amount' DE use a semantic note in the segemnt definition to provide the
> semantic constraint to a single constraint value (e.g., to represent 'Net'
> amount).)
> How an 'amount' is represented in a particular syntax must not be a factor
> in defining 'amount' as a Core Component.
> I am perfectly comfortable with having multiple physical representations
> an 'amount' in X12 syntax, in XML syntax, in EDIFACT syntax.
> That X12 chooses to use semantic notes in some cases to constrain semantic
> meaning, or perhaps uses a composite to relate the properties of an amount
> is not a problem to me.  That one might define both an 'amount' XML
> having fixed or variable attributes to specify properties, or having
> pointers to other elements which convey those same properties is not a
> problem to me.  Defining a document in which there is no documented way to
> associate an amount with its required properties is a problem to me.
> It is instructive to look at each of the X12 segments in which one or more
> 'amount' DE's are defined.  There are some instances in which a property
> an 'amount' cannot be discerned from the segment documentation.  There are
> also instances in which a semantic constraint property has multiple
> simultaneous values.  And there is at least one instance in which the
> ability to express an amount in non-numeric terms is provided.
> Cheers,
>          Bob
> -----Original Message-----
> From: Gregory, Arofan [mailto:arofan.gregory@commerceone.com]
> Sent: Thursday, May 31, 2001 2:05 PM
> To: 'William J. Kammerer'; ebXML Core
> Subject: RE: William defends Todd's dignity, too... and also wonders
> where the qualifiers went...
> William:
> There has been a good deal of discussion about the use of qualifiers
> generally in core components design in the working groups.
> I will attempt to paraphrase:
> In EDI syntaxes, qualifiers are used to indicate semantic specific to the
> local use of a re-usable component (for example, is this a Buyer party or
> Ship To Party?)
> In some XML syntaxes, a similar approach is used (xCBL uses qualifying
> in many places, although certainly not everywhere, and usually for
> with EDI syntaxes).
> In other XML syntaxes - especially those based on XML DTDs, which have a
> weaker concept of a "code list" or "enumerated datatype" - semantic
> qualification is performed with element containership. Now that we have a
> standard schema language to work with, that gives us strong typing
> capabilities, we have another mechanism for indicating semantic
> qualification with element names: a Buyer Party becomes an element named
> "BuyerParty" with a type attribute that indicates it is a "Party".
> In short, depending on how core components are bound to a syntax,
> codes may or may not be useful.
> I believe that the core components models did not indicate complete
> eumerations for the semantic qualifications of core components, but merely
> indicated the types of existing lists that might be useful.
> Ultimately, what we care about in the core component models is a range of
> standard uses, whether these are bound to a syntax as qualifying codes or
> with some other mechanism. Given the way XML processors work, I think it
> very likely that many XML formats will not use qualifying codes as the
> way of indicating local semantic qualifications, because they are an
> inconvenient way to model XML data, having the disadvantage of containing
> within their content the information about what they are, rather than
> this be present as a container, and thus immediately available to
> event-based processors such as those using a SAX interface. I may be
> Regardless, I don't think the issue is one of qualifying codes or not, but
> merely one of capturing a standard set of qualifiers that can be bound to
> specific syntaxes in many different ways.
> I hope this summary of discussion at some of the ebXML meeting will prove
> helpful.
> In response to Todd, I would say that perhaps we have not yet made the
> effort to enumerate all of the potential uses for these components. I
> believe that we have done a lot of work that may be useful in producing
> an enumeration, but that this activity was not determined to be in scope
> to this point. Maybe now is the time to start working on a standard set of
> local uses for each of the components?
> Cheers,
> Arofan Gregory
> -----Original Message-----
> From: William J. Kammerer [mailto:wkammerer@foresightcorp.com]
> Sent: Thursday, May 31, 2001 11:38 AM
> To: ebXML Core
> Subject: William defends Todd's dignity, too... and also wonders where
> the qualifiers went...
> Todd Boyle asks why don't the dateTime and Amount core components have
> qualifiers which explain what the dateTime and Amount are all about?
> This was a reasonable question which should be dignified with an answer.
> Perhaps it was missed because it was posted to the ebxml-dev mailing
> list rather than the Core Components mailing list.  See
> http://lists.ebxml.org/archives/ebxml-dev/200105/msg00009.html.  To
> repeat Todd's question: Is 'qualifier' in the doghouse?
> Anyway, Todd's asking the same questions I asked a long time ago, to
> which I never received an answer.    See the third paragraph in
> http://lists.ebxml.org/archives/ebxml-core/200104/msg00279.html.
> Todd's question should be seriously mulled over - this is extremely
> relevant to Core Components design.  And it is a bit more important than
> cat-fights over XML syntax.
> William J. Kammerer
> 4950 Blazer Pkwy.
> Dublin, OH USA 43017-3305
> +1 614 791-1600
> Visit FORESIGHT Corp. at http://www.foresightcorp.com/
> "accelerating time-to-trade"
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org
> ------------------------------------------------------------------
> 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