OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [ubl-dev] Datatype Methodology RE: [ubl-dev] SBS and Restricted Data Types


David,
 
Thanks for acclimating to my off-the-cuff acronyms. However, I'll bet
that you are doing some work at the Department of Energy:) So we should
change:
 
<Quote>
otherwise we are moving more and more toward the DOE/DOP hybrid needs.
Conversely parent/child relations with key values and lookup codelists -
hint you are in the DOE world.

 

Clearly CAM is not a pure DOP tool - but it certainly supports the
notion of hybrid DOE/DOP needs.

</Quote>
 
to:
 
<Quote>
otherwise we are moving more and more toward the DEP/DOP hybrid needs.
Conversely parent/child relations with key values and lookup codelists -
hint you are in the DEP world.

 

Clearly CAM is not a pure DOP tool - but it certainly supports the
notion of hybrid DEP/DOP needs.

</Quote>
 
Joe
 
Joseph Chiusano
Associate
Booz Allen Hamilton
 
700 13th St. NW, Suite 1100
Washington, DC 20005
O: 202-508-6514  
C: 202-251-0731
Visit us online@ http://www.boozallen.com
<blocked::http://www.boozallen.com/> 
 

________________________________

From: David RR Webber (XML) [mailto:david@drrw.info] 
Sent: Tuesday, May 09, 2006 11:12 AM
To: Chiusano Joseph
Cc: stephen.green@systml.co.uk; ubl-dev@lists.oasis-open.org
Subject: RE: [ubl-dev] Datatype Methodology RE: [ubl-dev] SBS and
Restricted Data Types


Joe,
 
Yes indeed; blurring of the line between DOP and DEP is where this has
been since the inception of XML/edi.
 
The notion I was articulating around fault tolerant interchanges is most
definately a DOP concept.  If you don't care about some data point -
don't sweat it!
 
An example is when say shipping notice information is included in a
transaction to a distributor - that information is just a pass-thru to
the actual shipper - say the valid GPS coordinates of the delivery
point.
 
The potential flexibility that XML brings to the table has been largely
stymied by a combination of DEP thinking and back-end legacy SQL
database marshalling and unmarshalling to tables and columns.
 
The DOP world does not have such inhibitions!

Perhaps the only line that is hard and fast between DOP and DEP is the
use of #ANY in the data model and recursion!  When you see either of
those being used - then you can know you are in DOP world - otherwise we
are moving more and more toward the DOE/DOP hybrid needs. Conversely
parent/child relations with key values and lookup codelists - hint you
are in the DOE world.
 
Clearly CAM is not a pure DOP tool - but it certainly supports the
notion of hybrid DOE/DOP needs.
 
DW



	-------- Original Message --------
	Subject: RE: [ubl-dev] Datatype Methodology RE: [ubl-dev] SBS
and
	Restricted Data Types
	From: "Chiusano Joseph" <chiusano_joseph@bah.com>
	Date: Tue, May 09, 2006 10:39 am
	To: <stephen.green@systml.co.uk>, <ubl-dev@lists.oasis-open.org>
	
	Steve,
	
	I think you hit the nail on the head here with your initial
statement
	below: 
	
	<Quote>
	Maybe there is a bit of a conflict here between UBL doing what
paper
	does and UBL doing what EDI does. Which is the priority for UBL?
EDI
	would seem to favour the fixed-width limitations analogous to
	restricting string lengths, etc.
	</Quote>
	
	I believe that this is fundamentally about what many call
	"document-oriented XML" vs. "data-oriented XML". I will caveat
that by
	saying that I believe that the line between the 2
approaches/mindsets
	has been blurring for some time (see my XML-DEV post[1] of
almost 3
	years ago where I expanded on this citing a US federal
initiative I was
	working on at the time). 
	
	I'm about to propose what I call "DOP" and "DEP" - please read
on (hint:
	I think you already know what each "D" stands for:).
	
	Here's the leadin: No one can be wrong in their view here. I've
read
	during this long thread that "fixed-length limitations are
anathema to
	*document-oriented* processing and are too *record-oriented*" -
which
	can't be wrong, as it's a document-oriented view of XML which
does not
	care about data types, much less restrictions to data types. It
is 100%
	valid for the uses and (many) users that it serves.
	
	Then there is the data-oriented mindset, which adopts the
	"schema-as-contract" view (i.e. the schema is the contract) to
ensure
	that the content that users/systems receive is the content that
they
	expect to receive - including aspects such as data type
constraints
	(e.g. string length, max possible value for dates, patterns for
	identifiers, etc.).
	
	There will also be combinations of both mindsets that are needed
for
	some adopters/implementations.
	
	I will therefore assert (though not using Schematron:) that
current and
	future UBL adopters will have both sets of needs. My current
client
	initiative - which primarily requires a data-oriented mindset -
is a
	perfect example of this.
	
	Now we get to "DOP" and "DEP":
	
	I propose that consideration be given to providing 2 profiles
(or
	whatever term is best) to UBL adopters in the future: a
	"Document-Oriented Profile (DOP)" and a "Data Exchange Profile
(DEP)".
	For example, the DEP could provide users with mechanisms for
restricting
	data types, while the DOP could concentrate more on XSLT and
	document-oriented needs (I defer to Ken's expertise for further
	expansion on this aspect).
	
	Expanding on DEP for a moment: I noted an interesting comment
earlier
	from Ken:
	
	<Quote>
	Jon has already requested the supplementing of code list
constraint
	checking with trading partner business rules in a single
Schematron
	pass, so I'm building into the 0.5 methodology a way to include
	arbitrary Schematron rules in addition to synthesized Schematron
rules
	so that trading partners can exchange and point to their own
	supplemental Schematron expressions that have constraints to be
included
	with, but considered higher priority, than the synthesized
Schematron
	rules.  BTW, I haven't figured the most elegant way to do this
yet, but
	I'm working on it.
	</Quote>
	
	For DEP, perhaps there can be a mechanism (which I haven't
thought out
	yet) for a user to specify their own "local" data type
restrictions in a
	separate schema that is then included (as sort of a "package
assembly")
	at run-time (here's where David comes in and says "CAM already
does
	this!:). This could be done in the same manner that Ken
describes just
	above. Perhaps there can be a standard mechanism (or guidelines)
for
	naming such custom data types, perhaps (thinking out loud) with
the
	constraining facet as part of the name (following the data type
name),
	as well as the actual constraint value. So something like
	"StringMin3Max50" or "IntegerMaxInclusive200", etc.
	
	Joe
	
	[1] http://lists.xml.org/archives/xml-dev/200306/msg00847.html
	
	Joseph Chiusano
	Associate
	Booz Allen Hamilton
	
	700 13th St. NW, Suite 1100
	Washington, DC 20005
	O: 202-508-6514  
	C: 202-251-0731
	Visit us online@ http://www.boozallen.com
	
	-----Original Message-----
	From: stephen.green@systml.co.uk
[mailto:stephen.green@systml.co.uk] 
	Sent: Monday, May 08, 2006 4:06 PM
	To: ubl-dev@lists.oasis-open.org
	Cc: ubl@lists.oasis-open.org
	Subject: Re: [ubl-dev] Datatype Methodology RE: [ubl-dev] SBS
and
	Restricted Data Types
	
	Maybe there is a bit of a conflict here between UBL doing what
paper
	does and UBL doing what EDI does. Which is the priority for UBL?
EDI
	would seem to favour the fixed-width limitations analogous to
	restricting string lengths, etc.
	
	I tend to agree with the document-centric view which Ken is
espousing.
	Paper invoices don't disallow more than three decimal places of
a limit
	of invoice line description (except by arbitrary document data
input
	processes rather than by the very nature of the concept of what
in
	business terms constitutes a printed invoice). How an input
clerk adds
	that data from the document to the finance system doesn't depend
on
	agreements about what an invoice should contain; not typically
in my
	experience (quite narrow experience). It might be agreed that
invoices
	have to be in EUR but that
	* probably * (there may be exceptions) doesn't mean that an
invoice in
	USD isn't a legally binding invoice.
	
	However it is entirely feasible that an invoice in USD will have
to be
	sent back to the sender because a trading agreement with the
supplier
	required invoices to be made out in EUR only.
	Likewise an invoice with an invalid Order Reference might be
returnable
	as contrary to business terms. Typically the application
limitations
	will lead to business terms allowing business to work smoothly.
Software
	facilities are just as much a reason to specify business terms
as
	banking facilities.
	I think there should be a way to express such requirements in a
way that
	is machine readable and/or unambiguous, such as with the
Codelist
	Methodology. Hence the possibility of a need to cater for other
	datatypes in something like the codelist context association
files.
	Maybe. Maybe a bit later though?
	
	All the best
	
	Steve
	
	
	
	
	Quoting "G. Ken Holman" <gkholman@CraneSoftwrights.com>:
	
	> At 2006-05-08 12:10 -0600, stephen.green@systml.co.uk wrote:
	>> Following the conversations prompted by Joseph Chiusano I've
an idea 
	>> UBL might need, besides its Codelist Methodology, a general 
	>> methodology for at least restricting datatypes and maybe
extending 
	>> them in some cases.
	>
	> I'm not yet convinced, but I don't want to stop the debate and
I may 
	> yet be swayed.
	>
	>> I was thinking that it is possible with UBL to extend and
restrict 
	>> enumerated codelists without it being called customisation.
Yet to do
	
	>> this with other datatypes it might be necessary at the
present to 
	>> call it customisation. How about in future adding to the
Codelist 
	>> Methodology a way to do the same or similar (as one can for 
	>> codelists) with other datatypes.
	>
	> But why is it being done in the first place?  It seems to me
to be 
	> accommodating vendors and not users, creating an artificial
limit to 
	> accommodate programs rather than letting business use what
they need 
	> and having the program accommodate the users.
	>
	>> A trading agreement which limits the currencies used to just
USD 
	>> might be such that a document with other currencies included
isn't 
	>> regarded as valid.
	>
	> From a business perspective, yes.
	>
	>> The codelist methodology allows for this. We seem to need a
way to 
	>> apply such criteria to datatypes other than codes.
	>
	> Again I'm interested to know why ... I know what you are
asking, but 
	> not the justification to limit some business users' needs for,
say, 
	> long description fields.
	>
	>> In some cases
	>> it might be that an instance is invalid with Text types
having an 
	>> over long string value. In other cases it might be that they
aren't 
	>> invalid but an non-fatal exception is raised (the latter
being more 
	>> along the lines of the SBS subsetting methodology).
	>
	> But is this being done because of poor program design that
arbitrarily
	
	> limits the string values rather than accommodating business
needs for 
	> long strings?  I thought I got away from string limits when I
got away
	
	> from programming in COBOL and RPG II ... those were the last 
	> programming languages I used where records were mapped to
fixed-length
	
	> fields.
	>
	> I think fixed-length limitations are anathema to
*document-oriented* 
	> processing and is too *record-oriented*.
	>
	>> Maybe the latter could be called 'UBL subsetting' and the
former 'UBL
	
	>> profiling' (the codelist methodology seeming to suggest 'UBL
	profiling'
	>> for codelists).
	>
	> Why not just "business rules" or "application rules"?
	>
	> Though I'm still not convinced they are justified.  If a
business user
	
	> finds the XML vocabulary suits their needs but the application

	> software doesn't, they could look for application software
that does.
	>  If they, then, decide that they cannot for whatever reason
change the
	
	> application, then they have a business rule for limiting it,
say, as a
	
	> non-fatal error message.
	>
	> Jon has already requested the supplementing of code list
constraint 
	> checking with trading partner business rules in a single
Schematron 
	> pass, so I'm building into the 0.5 methodology a way to
include 
	> arbitrary Schematron rules in addition to synthesized
Schematron rules
	
	> so that trading partners can exchange and point to their own 
	> supplemental Schematron expressions that have constraints to
be 
	> included with, but considered higher priority, than the
synthesized 
	> Schematron rules.  BTW, I haven't figured the most elegant way
to do 
	> this yet, but I'm working on it.
	>
	> But, again, string limitations are just not (to me)
document-oriented.
	
	> If a business user needs to express their line item
description in 
	> 1001 characters, then using 1000 characters must not have been

	> appropriate.
	>
	> . . . . . . . . . . . . . Ken
	>
	> --
	> Registration open for XSLT/XSL-FO training: Wash.,DC
2006-06-12/16
	> Also for XSLT/XSL-FO training:    Minneapolis, MN
2006-07-31/08-04
	> Also for XML/XSLT/XSL-FO training:Birmingham,England
2006-05-22/25
	> Also for XSLT/XSL-FO training:    Copenhagen,Denmark
2006-05-08/11
	> World-wide on-site corporate, govt. & user group XML/XSL
training.
	> G. Ken Holman
mailto:gkholman@CraneSoftwrights.com
	> Crane Softwrights Ltd.
http://www.CraneSoftwrights.com/o/
	> Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999
(F:-0995)
	> Male Cancer Awareness Aug'05
http://www.CraneSoftwrights.com/o/bc
	> Legal business disclaimers:
http://www.CraneSoftwrights.com/legal
	>
	>
	>
---------------------------------------------------------------------
	> This publicly archived list supports open discussion on
implementing 
	> the UBL OASIS Standard. To minimize spam in the archives, you
must 
	> subscribe before posting.
	>
	> [Un]Subscribe/change address:
http://www.oasis-open.org/mlmanage/
	> Alternately, using email:
list-[un]subscribe@lists.oasis-open.org
	> List archives: http://lists.oasis-open.org/archives/ubl-dev/
	> Committee homepage: http://www.oasis-open.org/committees/ubl/
	> List Guidelines:
http://www.oasis-open.org/maillists/guidelines.php
	> Join OASIS: http://www.oasis-open.org/join/
	>
	>
	
	
	
	
	
---------------------------------------------------------------------
	This publicly archived list supports open discussion on
implementing the
	UBL OASIS Standard. To minimize spam in the archives, you must
subscribe
	before posting.
	
	[Un]Subscribe/change address:
http://www.oasis-open.org/mlmanage/
	Alternately, using email:
list-[un]subscribe@lists.oasis-open.org
	List archives: http://lists.oasis-open.org/archives/ubl-dev/
	Committee homepage: http://www.oasis-open.org/committees/ubl/
	List Guidelines:
http://www.oasis-open.org/maillists/guidelines.php
	Join OASIS: http://www.oasis-open.org/join/
	
	
---------------------------------------------------------------------
	This publicly archived list supports open discussion on
implementing the UBL OASIS Standard. To minimize spam in the
	archives, you must subscribe before posting.
	
	[Un]Subscribe/change address:
http://www.oasis-open.org/mlmanage/
	Alternately, using email:
list-[un]subscribe@lists.oasis-open.org
	List archives: http://lists.oasis-open.org/archives/ubl-dev/
	Committee homepage: http://www.oasis-open.org/committees/ubl/
	List Guidelines:
http://www.oasis-open.org/maillists/guidelines.php
	Join OASIS: http://www.oasis-open.org/join/ 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]