[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC