EDI Electronic Notary rather then VANS

["Stephen GOULD" <stephen.gould@halisa.net>]

David - Hereby we have a conundrum - 99.9 % of the people do not

understand how Money or Economics work which has been around 

for 100 year and they hear about it every day let alone XML and Data 
Communications !


When it is electronic you do not know where the money is going !


A   Tax being replaced by Value Added Services Costs

B   Electronic Notary rather than Value Added Network Service

C   Differences in Legal Practices

D  Next Steps - XML Developers using Complex Address version 


A    TAX BEING REPLACED BY VALUE ADDED SERVICE


Tax is a Feudal Term and with electronics the new name is "Value 

Added Service".


As the banks have recognised if all transactions are electronic what 

is the role of the Bank  - unless they can provide a Translation service

like Currency Exchange ?.


In EDI many of the Value Added Network Services are called CANS 

(Cost Added Network Services) by the Users as they add Cost  rather 

than provide Value.


Please extend your timescale to think in terms of decades for the

electronic framework legislation to be put in place and people

trained on the new eGovernment processes


Hence although the Electronic Transaction Acts have been put in place

3 or 4 years ago in Each State, it is only now that the Local Councils

are starting to provide Electronic tenders and other "Reduced Regulation" 

Forms on the Internet.

http://www.oic.org/cpt/A/Ect/


First of all the Government has to create the Red tape and Regulations

before the wonderful world of Electronics can reduce the Regulation


If you are used to paying $ 20.00 for a Government Service and it is now 

only $ 5.00 to do it electronically what a saving !

 


In the meantime there is, we believe, special tax concession for projects

that encourage the use of email and the Internet - hence many ISP

appear to support SPAM and in Australia the electronic Pokies

provide a bonanza for the State Government coffers with the tax

being sent electronically every time the Pokie (slot machine) is 

played.


In the US that may be why all the Indian Reservations have all the 

gambling machines


Most sports programs over here on Radio and Television encourage 

sms and email response.


B    ELECTRONIC NOTARY


I attended a one week EDI Conference in Brussels in 1989 where

it was announced that the Plan was in 2015 there would be no reserve 

telephone charges (ie free telephoning).


When I asked whose Plan was that everyone around me started to 

laugh


Here is a link to the TEDIS Legal Workshop at that Conference

when Francoise CHAMOUX from France put forward the concept 

of an Electronic Notary

http://www.halisa.net/H/AEECECTL.gif


This Electronic Notary fitted in with our own research in 1988 for 

the eCommunications in Insurance Industry between Client/Agent/

Broker/Underwriter

http://www.halisa.net/R/Ins/HINRUBM3.jpg


An Electronic Notary is an independent organisation that recorded that

A had sent B a message (quotation/invoice/payment) and the message 

had been received ie in the event of a dispute the Electronic Notary

can produce the evidence of who sent what to whom and when.


C    DIFFERENCES IN LEGAL PRACTICES


Now you probably appreciate that Napoleonic Law in France has

Judges as Inquisitors who have to investigate to discover the truth.


Whereas in US, English and Australian Law the Judge makes a decision

based on the Argument put forward by the Barristers for the Plaintiff 

and the Defendants which must include Precedents (previous Judgements)

to support the Argument


Hence the French proposed the Electronic Notary because it fitted

in with their legal process whereas for the US, English it is the debate

rather than the truth that is the objective of the Legal process


However with the 1992 Maastritch Treaty in Europe Napoleonic Law

is being replaced probable with Dispute Resolution eProcesses which

use a lot of band-width !


NEXT STEPS


This is why the two Address Options within the Australian Standard

eCommerce Standard AS 4590 and the UN/CEFACT Standard is

so important for XML Developers to understand.


If the XML Developers ensure that the AS 4590 Complex Address 

Format is used then the VANS will not have to provide a Check and 

Translate Service - and every one will save money

http://www.oic.org/z/XZIG/AS4590/add/


What do you think ?


How can we explain this to the XML Developer Community ?


Regards


Stephen GOULD



On 19 Dec 06, at 19:30, David RR Webber (XML) wrote:


Stephen,



Humour me a minute here - seems that the Australian gov is charging a tax on 
EDI-style transactions, but not on email, html and PDF?



So - what's to stop people either:



1) basing their EDI / xml servers off-shore - say in New Zealand - and using 
RPCs with parameters to push data - and then retrieve as either <<html> wrapped 
content or SQL requests via SSL.



2) using <<html> mimetype - but with CDATA section that contains the actual 
XML or EDI - so technically its a <<html> transaction.



3) What does the Australian government do about Amazon.com and eBay 
stores - like this one of mine - that is pure XML with xslt based? 
<underline><color><param>0000,0000,FF00</param>http://readingheaven.com/chess/</underline></color> would they want to charge tax onch page 
impression? If NOT - then again this kind of setup could work in reverse as a 
proxy to exchange XML to a B2B server behind it - off shore (see the Search 
feature on my page - returns pure XML).



Or put another way - why are you crazy SOBs still paying this ludicrous 
eTax?!?



DW

"The way to be is to do" - Confucius (551-472 B.C.)






<paraindent><param>left</param>-------- Original Message --------
Subject: [ebxml-dev] Electronic Transaction Act
From: "Stephen GOULD" <<stephen.gould@halisa.net>
Date: Tue, December 19, 2006 10:26 am
To: ubl-dev@lists.oasis-open.org, ebxml-dev@lists.ebxml.org
Cc: "HIN"<<hinacgl1@halisa.net>

Fulton -Thank you for the response - lets see if I can illuminate some 
of the points you made 

A Legislation referred to as eTax
B BizDex and Local Government eCommerce Application
C Port of Melbourne eCommerce application
D PDF files - unnecessary overhead
E Next Steps

A LEGISLATION REFERRED TO AS ETAX

eTax refers to legislation called the Electronic Transaction Act - passed
by Australia Federal Government in 1999 and each State in 2000-2003 
http://www.halisa.net/fam/gov/loc/

Australia is the only country that has passed Electronic Transaction Acts

> It is not obvious how perpetuating inefficient messaging provides any
> financial benefit to the Australian government.

If you review some of the recent Government tenders that have been 
published on the OTMG Tender Information Management Service 
[TIMS] to
make Natural resources such as water etc as Market Based 
Instruments 
http://www.oic.org/cpt/A/Ect/#e

And if you can understand that Government Agencies have to place 
electronic Bids every 15 minutes then that becomes significant 
http://www.oic.org/cpt/A/Ect/#l

And each Council has to develop Recreation Strategies whereby
Floodlights and Irrigation Systems are required for each sports field
http://www.oic.org/cpt/A/Ect/#r

B BIZDEX AND LOCAL GOVERNMENT

One of the tenders that has been published is for a Consortium of
32 Victorian Councils for rate-payers to apply electronically for 25 
different 
permits and building applications - non critical applications - the 
EasyBiz Consortium.

The contract for the eHub is with not-for profit organisation called 
Bizdex

These are the Owners which inlcude IBM, Microsoft, Intel 
http://www.bizdex.com.au/page.php?file=who_owns_bizdex

BizDex was developed for the Australian Wheat Board from a 
Government
grant to assist with the export of Australian Wheat by AWB

BizDex has stipulated the use of the Australian eCommerce Standard
AS 4590 as part of a tender to outsource the integration into the 
Council applications
http://www.smeems.net/z/LZIG/tdr/ICoHAWJ9/

In addition the Port of Melbourne has published a tender for an 
eCommerce Pilot
http://www.oic.org/z/XZIG/tdr/BCbAAWL7/

If there has to be an electronic check on which address format is used 
for every 
message that is a considerable Value Added Service !

E PDF FILES UNNECESSARY LOCAL GOVERNMENT 
OVERHEAD

All the Councils provided their minutes as PDF files

As an example here is is a link to McALLEN City in South Texas which 
warns many of the minutes are over 50Mb !
http://www.mcallen.net/officials/meetings.aspx 

If you want to view the minutes you have to download the PDF file 
and laboriously scroll through the file.

Compare that with how legislation is presented as htm files and
see the difference
eg Federal Electronic Transaction Act
http://www.austlii.edu.au/au/legis/cth/consol_act/eta1999256/

And Electronic Committee Information Management [ECIM] developed
by OIC members as part of the Electronic Association Information
Management [EAIM]

This is ECIM implemented in a local Volunteer Sports Club so that
people can track the issues though the minutes (thread) and not
just have a pdf file that cannot provided the history of the issue 
http://www.smeems.net/fam/soc/pit/mgt/mcm/

A version has been used to keep a record of the communications 
on the two address data elements in UN/CEFACT
http://www.oic.org/z/XZIG/UNCEFACT/

NEXT STEPS

Hence this may help illustrate why have a single NAD address
is very important both within AS 4590 and UN/EDIFACT

Your comments appreciated

Regards

Stephen GOULD

On 15 Dec 06, at 21:23, Fulton Wilcox wrote:

> Stephen,
> 
> Two points regarding your note.
> 
> First, I assume that your term "eTax" is a reference to the Australian 
eTax
> electronic tax filing service.
> http://ato.gov.au/individuals/sitemap.asp?type=main . 
> 
> It is not obvious how perpetuating inefficient messaging provides any
> financial benefit to the Australian government.
> 
> With respect to the Australian government relying on PDFs to 
distribute
> tenders (request for bids), it would seem likely that it has to because 
PDF
> is pretty much the lowest common denominator for document delivery. 
Although
> I am not a fan of PDF, it is a workhorse.
> 
> Second, it is probably not realistic that, as you wrote, "single XML
> standards" be "...enforced by groups like the XML developers and 
UBL
> developers." There are at least four constraints: a) it isn't clear that 
XML
> developers actually agree on a single standard, because there are a 
variety
> of industry and other variants, b) the larger IT community, notably 
those
> who build and configure ERP and other applications, have powerful 
influence
> in defining the payload data, c) the dead hand of history, which keeps
> legacy practices in being, either in original form (e.g., ANSI EDI) or in
> updated representations, and d) technology evolution which unsettles
> previously settled standards. 
> 
> Therefore, although aspiring to "single XML standards" is worthy, the 
more
> likely avenue to interoperability is a more pluralistic approach to
> standardization, complemented by on-the-fly adaptation and translation 
made
> feasible by system-to-system negotiation of "how do we interoperate?" 
using
> definitional services based on standards such as ebXML. 
> 
> 
> Regards,
> 
> Fulton Wilcox
> Colts Neck Solutions LLC
> 
> -----Original Message-----
> From: Stephen GOULD [mailto:stephen.gould@halisa.net] 
> Sent: Saturday, December 16, 2006 6:00 AM
> To: ubl-dev@lists.oasis-open.org; xml-dev@lists.xml.org
> Cc: HIN; eConsultants
> Subject: RE: [ubl-dev] Time to review Edifact NAD format ?
> 
> David - Thanks for your response - I appreciate the whole point of
> EDI was to provide prescribed formats and not allow flexibility.
> 
> Which is why you have to understand the Politics behind EDI and 
> why it was driven in Australia by the Banking Industry Association
> ref EDI/11 meetings 1987
> http://www.halisa.net/A/U/SME/
> 
> The Politics is extremely important because Australia is the only
> Country which has passed legislation call the Electronic Transaction
> Acts both at Federal and State Level as part of the "Information
> Economy"
> http://www.halisa.net/fam/gov/loc/
> 
> This mean the Government receives "eTax" for each electronic 
Transaction
> hence the Government has a great interest in inefficient messaging
> systems with confusing Standards and sending large files eg PDF 
> files on Government tenders
> http://www.smeems.net/Q/AW/K/CPTWK4AC.htm
> 
> Australia has been the development site for EDI since 1987 with
> 18 out of the 99 UN/EDI Rapporters based in Australia
> Rfe Paula SWATMAN EDI Council of Australia 1992
> http://www.halisa.net/R/EDIACPR1.htm
> 
> And two Australian at the top of the Customs Co-operation Council
> in Brussels for 5 years - one as the Secretary General and one as 
> the Head of Administration
> http://www.halisa.net/C1/Ccc1.jpg
> 
> There a number of other issues which is why a group of consultants 
> formed the OIC XML CEFACT Work Gp for two major EDI projects 
in 
> Australia that stipulate the use of UN/CEFACT and AS 4590
> - one with the Ports and one with 32 Local Councils
> http://www.smeems.net/oicdata/3d1.asp
> 
> NEXT STEPS
> 
> We are trying to resolve these issues through UN/CEFACT
> http://www.oic.org/z/XZIG/UNCEFACT/
> 
> However we need the support from the rest of the EDI Community to 
> make sure that single XML standards are created and more important 
> enforced by groups like the XML developers and UBL developers
> lists
> 
> Regards
> 
> Stephen GOULD
> on behalf of the Management and IT Consultants 
> HALISA INTERNATIONAL NETWORK
> 
> On 14 Dec 06, at 8:27, David RR Webber (XML) wrote:
> 
> > Stephen,  
> > 
> > Have you looked at creating a profile for NAD using OASIS CIQ? 
> > Remember the whole point of EDI was to perscribe - not allow
> > flexibility!!! Even the UPU acknowledges that accelerating
> > computerization and modern mail volumes has resulted in reduced 
options
> > and dependency on uni-formats. E.g. I used to be able to address
> > something to - 'Third house on the left, pass the Lamb and Flag, with
> > the pink shutters and red front door, Henlade, Somerset, England'. 
> > Now that comes back as 'No Post Code - address unknown' ; -)
> > 
> > I did forward your original message to Ram Kumar - he is in Sydney 
- and
> > I'm sure would be happy to assist further.  
> > 
> > DW
> > 
> > "The way to be is to do" - Confucius (551-472 B.C.)
> > 
> > 
> > -------- Original Message --------
> > Subject: [ubl-dev] Time to review Edifact NAD format ?
> > From: "Stephen GOULD" <<stephen.gould@halisa.net>
> > Date: Thu, December 14, 2006 6:51 pm
> > To: ubl-dev@lists.oasis-open.org
> > 
> > EDI is proving to be a disaster around the world mainly because the
> > Standards were formulated over 20 years ago with the driving force 
being
> > to reduce Purchasing costs not facilitate Trade 
> > 
> > EDIFACT was first release in 1987 and the format has not been 
> > revised hence the normal business problem of unclear instruction
> > results in mayhem.
> > 
> > There are two address formats in the NAD Data Segment without 
> > any directions to stipulate when each format should be used
> > 
> > With the advent of XML and the Internet perhaps it is time to have 
very 
> > clear instructions when to use each format or just reduce it to one 
> > format only
> > 
> > A TECHNICAL PROBLEM WITH MULTIPLE ADDRESS 
FORMATS
> > 
> > The OIC Expert IT eCommittee formed to resolve the single XML 
address
> > for ASA 4590 has initially confirmed that the Complex version can
> > replace
> > the Simplex version to establish a single XML Address format
> > 
> > It now appears that UN/CEFACT (EDIFACT) has the same 
problem with 
> > different options in the Name and Address (NAD) Data Segment 
for each
> > Trade Document 
> > 
> > Whilst I appreciate you will not have reviewed the details of the data 
> > elements and data components of UN/CEFACT, here is a link to the 
> > "NAD" Data Segments and three eTrade documents downloaded 
from the 
> > Australia TradeGate Importer/Exporter Web Site
> > http://www.oic.org/z/XZIG/UNCEFACT/ZXAAECR1.htm
> > 
> > As you can see there will be much confusion as to whether 
software 
> > developers should use Data Element CO58 or CO80 and CO59.
> > 
> > However the main problem is that software will have to be written
> > to check which whether "CO58 has been used" or whether "CO80 
has 
> > been used thru to 3207"
> > http://www.halisa.net/R/EDIFACT/edieraa1.htm
> > 
> > B PORT OF MELBOURNE EOI 13110
> > 
> > The Government Responses to Questions to the Port of Melbourne 
> > eCommunity PoMC EOI 13110 indicates there is much confusion 
from 
> > Government responses on the use of Ecommerce Standards
> > http://www.oic.org/z/XZIG/tdr/BCbAAWL7/BCbAAWQ1.htm#Ah
> > 
> > It is appropriate UN/CEFACT to clarify the issues prior to the RFT 
being
> > 
> > published as EOI 13110 states all importers and exporters must use 
> > EDIFACT.
> > 
> > C UN/CEFACT SUPPORT FOR TRADE FACILITATION
> > 
> > The Mission Statement of UN/CEFACT states it "supports activities 
> > dedicated to improving the ability of business, trade and 
administrative
> > 
> > organizations, from developed, developing and transitional 
economies, 
> > to exchange products and relevant services effectively"
> > http://www.oic.org/z/FZIG/AUJS/p/C/1UCAAEB1.htm
> > 
> > In Sep 2004 you and I reviewed your draft eCommerce Trade 
Strategy
> > for the Asia Pacific Region
> > http://www.oic.org/A/U/
> > 
> > On reviewing that Strategy again, I believe the key issue for Trade
> > Facilitation is the single address format within the "NAD" Data 
Segment 
> > for all eTrade Documents.
> > 
> > Hence I believe the recommendations on the AS 4590 Standard will 
be
> > pertinent to UN/CEFACT.
> > 
> > NEXT STEPS
> > 
> > What do you think ?
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
> > For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org <FontFamily><param>Times New Roman</param><bigger></paraindent>