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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: Use of Tags

[ Lists Home | Date Index | Thread Index ]
  • From: "Jonathan Borden" <jborden@mediaone.net>
  • To: "xml-dev Mailing List (E-mail)" <xml-dev@ic.ac.uk>
  • Date: Wed, 21 Apr 1999 20:04:51 -0400

I have been asked to clarify this paragraph:

>
>    And if this objection to the use of elements is sufficiently handled in
>this fashion, are there other pressing reasons why values (particularly
>table columns) ought be expressed as attributes rather than elements? To me
>the most pressing reason to use elements to encode "recordsets" is that in
>the absense of a schema decl or DTD, the content can be correctly
>interpreted. For example when converting to and from SQL, "int" values
>though textualy represented are not 'quoted' while character values are
>e.g.: UPDATE table SET intval = 3, charval='3' or
>    SELECT FROM table WHERE intval = 3 OR charval = '3'
>
    I have recently developed as system to insert, update and query
relational table schemas using XML documents and XSL transforms, this allows
storage of XML documents in relational tables which are designed to
efficiently model the underlying data hierarchy (that is a single XML
document maps to perhaps many inserts, updates and selects on the underlying
relational db. this technology is very similar to data shaping but is
entirely based upon XML and XSL transforms).

    I have developed this for our medical records system, for those of you
who are aware of the HL7 V3 object model, you are aware that it is a complex
network of relationships. Patient demographics and other information is
modelled as a graph which is serialized as XML for transmission over the
web. The client side uses a cluster of transformations to map this graph
onto various forms and web entry screens, the server side uses
transformations to map this graph onto the underlying relational database
model (the HL7 model). So in doing this, properly and efficiently
representing relational data as XML is very important. I would love to use
attribute whenever possible for efficiency concerns yet I appear to require
elements for practical issues. I've read Andrew Layman's article on
serializing graphs, and the recommendation that properties/arcs be
attributes yet I'm not sure how to type these values in a way that my XSL
processor can make sense of.

    Suppose I encode a recordset in the following fashion:

<row a="3" b="da da da" c="42 Washington Street" d="42" />

In the absense of a schema which describes the recordset, how do I apply a
type to 'a="3"' does this mean the string "3" or the number 3?

For example,
<row>
    <a dt:dt="int">3</a>
    ...
    <d dt:dt="string">42</d>
</row>

The value types are unambiguous.

What I am getting at in regard to using SQL (which is a common task when
dealing with recordsets) if you desire to create an XSL transform which
converts recordsets into SQL statements, e.g. to INSERT a recordset into a
table, you need to know what the datatype is. Both XML and SQL are text
based but SQL has a different syntax for values which are intended to
represent character strings vs. those which are intended to represent
numbers, e.g.:

INSERT tab (a,d) VALUES(3,'42')  is the correct syntax whereas:

INSERT tab (a,d) VALUES('3','42') generates an error if column 'a' is typed
as an int.

so 3 is generated as
<template match=".[@dt:dt = 'int']><value-of/></template>

where '3'
<template match=".[@dt:dt='string']>'<value-of />'</template>

Jonathan Borden
http://jabr.ne.mediaone.net



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS