[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 range > limits); a currency designation (or a means to derive same from elsewhere in > the document or schema); a semantic constraint (e.g., some (super/)subset of > 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 of > 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 element > 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 of > 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 a > Ship To Party?) > > In some XML syntaxes, a similar approach is used (xCBL uses qualifying codes > in many places, although certainly not everywhere, and usually for agreement > 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, qualifying > 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 main > 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 having > this be present as a container, and thus immediately available to > event-based processors such as those using a SAX interface. I may be wrong. > > 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 such > an enumeration, but that this activity was not determined to be in scope up > 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 > FORESIGHT Corp. > 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]
Powered by eList eXpress LLC