RE: William defends Todd's dignity,too... and also wonders where the qualifiers went...

["Gregory, Arofan" <arofan.gregory@commerceone.com>]

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