[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: archiving with xml

• To: "Michael Kay" <mike@s...>,"'Rick Marshall'" <rjm@z...>,<xml-dev@l...>
• Subject: Re: archiving with xml
• From: "TAN Kuan Hui" <kuanhui@x...>
• Date: Tue, 5 Apr 2005 10:03:52 +0800
• Organization: Xemantics Software Pte Ltd

>
> In this country, I believe that any electronically archived information is
> only as good as your ability to prove that it is a reliable record of past
> events, which depends on showing that you had well documented processes and
> that you followed them.
>
> Michael Kay
> http://www.saxonica.com/
>
In my country, Singapore, you will have to implement a system and <process>
that conforms to the requirements of the Evidence Act.

You can reference the act here,
http://statutes.agc.gov.sg/non_version/cgi-bin/cgi_retrieve.pl?&actno=Reved-97&date=latest&method=part

See particularly Section 35 which is relevant to the discussion.

A reliable set of undisputable records needs to have the system and
processes audited by an independent party at the point when
the system goes operational and also on a periodic basis to ensure that
the people operating the system conforms to laid down procedures.
On top of what you have highlighted, there is a need for periodic
audit by an independent un-disputable auditor who can say that
you have indeed followed the laid down processes.

I have implemented an imaging and database system a couple
of years back that was audited by E&Y to conform to the act.
Extrapolating from that experience to the discussion here,
it is my opinion that the minor rendering differences between xslt
engines is not a significant consideration. The truth of the data
with respect to the xslt code itself is however significant as it
interpretes the data and presents the truth. Well, that is the
basis of the whole xml story isn't it ? That content
is seperated from presentation instances. As discussed
elsewhere on this thread, the key consideration I would like
to highlight is where this truth lies. If its strictly encapsulated in the
xml content and that information is truthfully presented via the xslt
or that the presentation is irrelevant then the xml data itself
is adequate as evidence.

The design of the xslt, and its interpretation of data as intended
would probably have to be audited. Once this is done,
changes to the xslt has to be tracked, versioned,
controlled and documented. If the system is well design, we
should only need to keep centralised xslt copies and its versions
and manage them as per any other data. There is no need to store
the xslt with the data for every instance. That redundancy will
potentially make the system more complicated for both
management and audit. There will also be a need to track in
the xslt which engine/xslt version it was intended for particularly
since there will be some backward compatibility issues with xslt 2.0
and 1.0. Therefore in this respect, you may need to keep
different versions of the xslt engines just to ensure that the
output can still be generated from the xslt that the xml content
referenced.

Kuan Hui

• Prev by Date: Re: Re: What Does SOAP/WS Do that A REST System Can't?
• Next by Date: Re: Re: What Does SOAP/WS Do that A REST System Can't?
• Previous by thread: RE: XML for press releases?
• Next by thread: Address Book vocabulary...
• Index(es):
  • Date
  • Thread