RE: Re(3) Regarding the Thursday ebXML Conf Call

["Duane Nickull" <duane@xmlglobal.com>]

Hi:

In response to the previous thread, I would like to give a small tutorial on
exactly what a Parser and  Handler do and how XLink is affected.  I think
this would be very useful in having everyone understand the issues.

The parser has a relatively simple job.  A parser is a reader.  That's all
it does.  It reads the incoming data and does nothing with it.

A Handler is like a verb.  The handler acts upon what the parser reads.  For
instance, if the parser finds an error, it may invoke a handler to produce
an error message to the standard output.

Most XML parsers have built in handlers for errors pertaining to whether or
not the XML is valid, well formed, syntactially correct or conforms to the
Authors interpretation of the XML specification.  They are all slightly
different due to various nuances in authors intepretations but most are
relatively conformant with the code.

If an XML parser has built in support (IE "Handlers") for XLink and it
encounters an XLINK with the "show" attribute value set to "embed" AND the
"actuate" set to "onLoad", it MUST follow the link to the data referenced,
get a copy of it (an important distinction), and embed it within the NODe
where the call originated from. The specification clearly states:

"An application traversing to the ending resource should load it for display
in place of the starting resource. This is similar to the effect achieved by
the following HTML fragment:"

Several error handlers "could" be associated with this action such as a
"time out" error handler, a "syntax checking" error handler or a "data not
available" (ie HTTP 404) error hanlder.

If the XLink handler is properly constructed in a valididating XML parser
(IE one that also reads the DTD and makes sure that the XML conforms to the
DTD - specifically to data types), and the XLink handler finds a link which
the DTD specifies as CDATA yet the data from the link is Binary, one would
suspect that a "Data Type" error handler would be invoked.  Again,  we go
the the latest draft (20000221):

"Just as for the HTML IMG element, embedding affects only the display of the
relevant resources; it does not dictate permanent transformation of the
starting resource. For example, if the ending resource is XML, it is not
parsed as if it were part of the starting resource."

The problem is largely  academic as no such parser with XLink support is
avaiable (to my knowledge) at this time, however, there will come a day when
there will be.  (Someone told me an interesting spin on the "Build it and
they will come" saying.  In XML, we are at the "They're coming - quick -
build something" stage ).

Here is an important distinction to make.  When a parser reads an incoming
XML document and it encounters an XLink, it does not necessarily HAVE TO
embed the data referenced by the link.  The "show" attribute and the
"actuate" attribute can be set so the data is merely referenced, which I
think is the end result we are looking for.  The actual link is just a
pointer to the data (just like pointers in C/C++).  This allows someone to
have a binary file referenced by an XML message and the actual XML message
is still deemed valid/well formed and is 100% textual.

THINK about the binary data we are describing.  It is not really part of the
XML message in the fact that there is no application which currently "reads"
and acts upon a JPG file (at least not for ebusiness applications).  Sure
medical images, architectural drawings are all part of a business
transaction but (and this is a big but) are the parser and the handler
really acting upon them OR are they for human eyes/another application.  I
think that if we really think about it,  we realize that the images are
really meant for another human or application.

XML is a textual language.  It can include references to other data types
(as it should).  An XML parser is not required to read binary data such as
JPG's.  The language was never designed for this funcionality.



My $0.02

Duane Nickull