Lists Home |
Date Index |
On Sun, 2006-07-23 at 23:48 +0100, peter murray-rust wrote:
> * encoding of complex documents (this was the original emphasis from
> SGML projects such as TEI and DOCBook)
> * non-textual content. MathML and CML were the first (ca 1998); now
> the whole of bioscience is built on XML
> * "data". strong input from Microsoft, IBM etc. ca 1998, with strong
> mapping onto RDBs.
> * processing languages such as XSLT
> * XML infrastructure (XSD, RELAX, etc.). XML has taken over middleware
> * rendering (e.g. SVG. SMIL)
> * message passing (SOAP, WSDL, etc.)
> Is there anything essentially different between business data and
> genomic data? They both need to be created, stored, transmitted,
> processed and perhaps repurposed.
I would not know. Business data is usually strongly typed these days
into strings, numbers, booleans, currency values and so forth. I don't
know if those are pressing issues for genomic data.
> At a general level they both
> require a formal specification (Schema), maybe an ontology,
> domain-specific tools for precessing them.
Often Business data doesn't need a formal specification or schema.
This requirement has really held back xml or at least kept it in the
domain of tightly coupled systems. We need to go loose-coupling in
future, not insist that a programmer has sat down beforehand and work
out the schema for every single document.
Let me give you a real world example situation.
Receptionist wants to type a shopping list. Must get schema created by
IT. Loaded on a web server. Schema loaded on the web server. Validated.
It is so complicated and requires so many resources that it just doesn't
An easier way is to just embed all the type information and have no
schema, no web server, nothing else. This can be typed:
Customer_Name&="Mr Fred Parker"
<Product Item> PLU&="A256" Qty#=5 Rate$=4.56</>
> I can appreciate that security, authenticity and proof of transaction
> will be important but they are not really XML issues. Of course they
> may require the client to be configured significantly differently
> from the applications I am interested in.
Yes, they definitely can be issues.
I'll give a very common example.
In business, a lot of companies want to encrypt their prices so that if
the file is copied by a competitor sales rep, the prices can't be easily
read out. That is because they couldn't get the encryption key file.
PLU&="A256" Name&="Kitchen Veneer" Rate$~=HD321_C
decrypted it would read..
PLU&="A256" Name&="Kitchen Veneer" Rate$=402.00
That's the most often asked encryption question that I get asked in the
industrial park. btw, ~ denotes an encrypted field.