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

What do Biztalk want to acheive?

  • From: "Didier PH Martin" <martind@n...>
  • To: "'XML Dev'" <xml-dev@i...>
  • Date: Tue, 23 Nov 1999 10:26:03 -0500

biztalk rdf
No its not a flame against Microsoft :-) Its a reflection on what a biztalk
message is trying to achieve and what is missing in the actual XML world to
have what biztalk is trying to achieve.

Funny note: Mark, you know what, my Outlook spell checker wants also to
replace the biztalk word with bestial :-))) every time I see that, I laugh.
Microsoft embedded some humor in its outlook spell checker :-)))

1. Background:
Documents transferred from one place to an other can contains several
elements not part of the information model this document serialize (if the
document is a data model serialization as found in e-commerce applications).
a) the first meta information is the <?xml?> processing instruction
providing meta information about the document format and parsing
instructions. This element is an answer to the questions: "How can I parse
this document?", "How is this document encoded", etc... So, the element
contains info about the encoding, the version and so on and so forth.
b) the document type or DTD information. This element points or include the
meta information about the document structure. This is an answer to the
question: "What is the document's structure?". For more precision on the
structure and the data content type, a schema can be used instead.
c) the third element not part of the information model is the
<?xml-stylesheet?> element. This element is an answer to the question: "How
do I render this document?". it provides sufficient information to render
the document. the style sheet could be externally linked or embedded in the
document. What is interesting thought is to examine the document when the
style sheet is embedded. The example below shows a style sheet embedded in
an XML document.

<?xml version="1.0"?>
<?xml-stylesheet href="#style" type="text/xsl" media="screen"?>
<!DOCTYPE MyInvoice
.... the doc type content here but the document type
	do not include any references to the xsl name space,
	only defines the MyInvoice document type ...
<xsl:stylesheet id="style"
....the style sheet content here...
.... the document content here.....

2. interesting facts to note about the previous example:
a) The document type do not mention anything about the style sheet.
Therefore the style sheet can be included in a document even if this
document type has no mention of the <xsl:stylesheet> element. According to
the XSLT recommendation, the above document is valid. Then, a validating
parser should only consider elements not part of the "xsl" namespace in its
validation process. <Question to the group> Is this the same for any other
elements part of a foreign namespace? <explanations> if we include elements
part of a different name space (i.e. a different name space than the defined
document type in the !doctype section). Then the validating parser should
not include these foreign name space elements in its validation process.
b) So, a validating parser can check for the document consistency even if
foreign name space elements are included in the document. For the moment,
without making a generalization on this, let's just consider that the "xsl"
name space can freely be included in the document without affecting its

Thus, we are able to include foreign "xsl" name space elements in the
"MyInvoice" document without affecting its consistency. We still deal with
the "MyInvoice" document type and therefore with the "MyInvoice" document.

3. What biztalk is trying to achieve?
Biztalk is trying to provide an answer to the following questions:
a) from whom (or what) is this document coming from?
b) to whom (or what) is this document going to?
c) In which process is this document involved?
d) What is the transport used to move this document to its destination ?

we can say that all these information are meta information about the
document or the data model. It is about the data model it is not the data
model. Thus, biztalk is trying to provide meta information about the
document. It does so, by creating a new document type and by including your
document as a fragment into the document type. Is this the best solution? I
do not know. Is there any alternative ways to do it? Yes you bet.

4. Suggestion:
As we did for style sheets, why not do the same thing for meta information.
To recap: the original data model document is augmented or includes the
following elements, which are, from the data model point of view external
and are either meta information or processing information.
a) link to or includes the document type meta information
b) link to or includes the rendition processing information
c) inclusion of the document format meta information

Thus, why not add other meta information link or inclusion. For instance, to
link or include RDF statements about the document. This way we can achieve
what Biztalk is trying to achieve but in a more standard way.
This could be done with:
a) a processing instruction as for style sheets(ex: if linked <?xml-meta
href="mymeta.rdf" ?> or if included <?xml-meta href="#rdf"?> )
b) as a specialized element (ex: <rdf:RDF>)

Note about (b). If it is true that validation do not involve foreign name
spaces like it is the case for the "xsl" name space, then we can already
include in a document a <rdf:RDF> section without affecting its structure
and therefore without affecting its validation with a DTD or schema.

Therefore, if we can include a <rdf:RDF> element, then we can answer to the
questions biztalk is trying to answer.
<?xml version="1.0"?>
<?xml-stylesheet href="#style" type="text/xsl" media="screen"?>
<!DOCTYPE MyInvoice
.... the doc type content here
<xsl:stylesheet id="style"
....the style sheet content here...
<biztalk:from>your humble servant</biztalk:from> <------  from whom (or
what) is this document coming from?
<biztalk:to>a potential buyer</biztalk:to> <------------  to whom (or what)
is this document going to?
<biztalk:procurement>billing</biztalk:procurement> <----  In which process
is this document involved?
.....more meta info about the document here ....
.... the document content here.....

Or if the industry would agree on a common messaging system. We could then
propose a set of properties like the librarian people did with the Dublin

Interesting things to note about the suggestion:
a) the document is not transformed into a fragment and included in an other
document. we instead included meta information about the document. The
document kept its integrity.
b) A common task group could define a set of properties for documents used
for messaging.
c) we leverage the standards, we are not creating new ones or letting a
manufacturer set the rules.

Note to Tim [Berners-Lee]
To create the semantic network, we need to be able to associate (or include)
meta information to the documents. On the web, document are transferred from
a server to a client with rendition instructions. Why not then also include
Meta information about this document so that the client gets the context for
this document, or meta information about this document. The key word here is
"context". In witch context this document is living in. Can we add some
meaning to this document existence?

But Tim, if I where rich enough I would be member of W3C and would propose
what I just mentioned in this document. But the only thing I can do is sing
"if I where a rich man...". I can be part of a IETF group because I can
afford it (its free) or be part of ISO (its also free) but not part of W3C
(its not free).

But what is important though, is not my W3C membership or my membership to a
golf club :-) It is that we start to discuss about the inclusion of meta
information in documents (as links or included). Make it clear that the
validation process for parsers do not concern foreign name space or standard
name spaces like "xsl" or "rdf" (the XSL name space is a good start to
illustrate this fact). Make it clear that something like biztalk is trying
to achieve is possible with the existing standards without affecting the
document integrity or structure. I do not say here to show that Microsoft is
wrong. I say here to show how something like biztalk is trying to acheive is
already part of the XML standards.

Didier PH Martin

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


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.