RE: [ubl-ndrsc] more input

["Schwarzhoff, Kelly" <kelly.schwarzhoff@commerceone.com>]

Title: RE: [ubl-ndrsc] more input

I agree, it is "key for whom". That's why I'm wondering what the use cases are, and the prioritization of those use cases.

However, when you say it is important for a hub and marketsite, yes that is true. However, they are also important for (medium to large) lots of supply chain integration projects, especially where high availability and throughput matter. This is very standard for large EDI customers; In fact, to force these throughput and high avaibility requirements, lots of EDI customers will require their vendors to sign SLAs.

Kelly

-----Original Message-----
From: Mike Rawlins [mailto:mike@rawlinsecconsulting.com]
Sent: Thursday, November 08, 2001 1:10 PM
To: UBL Design Rules (E-mail)
Subject: Re: [ubl-ndrsc] more input

"Schwarzhoff, Kelly" wrote<snipped>:

> Are there specific use cases--and prioritization of those use cases--that
> drive these various design rules? The reason I ask is that some of the
> design rules don't seem to be driven by the practical technology and
> business constraints. Most obvious, I'm thinking about the "Processing
> Requirements" design which says schemas should not be designed around
> computer resources needed to process the documents.
>
> Having spent my last 3 years building and designing XML tools, I'd have to
> say that design rule seems rather theoretical. Ultimately, the schemas and
> documents you produce must work with tools; The less tools they support--or
> even the more expensive the use of tools is--, the less adoption of your
> schemas and standards, and thus driving up implementation and integration
> costs. This is especially the case in critical supply chain integration
> scenarios where throughput, high availability, deployment topology, etc. is
> key.

I think the question here is "key for whom?".  The things you mention in your
last sentence might be very important for a market-site or a large hub.
However, they are nearly totally irrelevant for a small supplier who just wants
to get documents in and out of MAS90 or PeachTree.  They're probably most
concerned with a human readability and an intuitive document structure so that
it doesn't take a very high priced consultant or programmer to do the
integration.  This is one of the reasons we kept coming up with "various and
sundry" as an answer to all sorts of design questions in the planning committee
discussions.  Lowest common denominator was also frequently mentioned.

--
Michael C. Rawlins, Rawlins EC Consulting
www.rawlinsecconsulting.com

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>