Re: To get things started.... Data formats

[David Lyon <djlyon@one.net.au>]

Good comments Eduardo,

> I was about to write a rather excoriating message in response to your
latest message,
> when I realized that I was mis-reading your example (and I assume Betty
was too).

Thanks for picking this up Eduardo.

> This being the case, it is one of the worst examples of XML I've ever
seen.

(lol) Thanks.

but they do make for messages that can be understood by Managers of SMEs
though. The only people they really confuse are the technical people. I
don't find that such a problem.

Take care

David


----- Original Message -----
From: Eduardo Gutentag <eduardo.gutentag@eng.sun.com>
To: Betty Harvey <ebxml@eccnet.eccnet.com>; David Lyon <djlyon@one.net.au>;
<ebxml-core@lists.ebxml.org>; <ebxml-dev@lists.ebxml.org>
Sent: Friday, June 01, 2001 3:30 AM
Subject: Re: To get things started.... Data formats


> David,
>
> I was about to write a rather excoriating message in response to your
latest message,
> when I realized that I was mis-reading your example (and I assume Betty
was too).
>
> What you are actually doing is eschewing the use of elements and
attributes in
> favor of simple content; what you have is:
>
> <Purchasor Details>Company_Name&="Hotwire Business Systems"
Address_Line_1&="38^/332 Handford Road" Address_Line_2&=""
Suburb_City&="Taigum" Region_State&="QLD"
> Postcode_ZIP&="4018" Country&="Australia" Telephone&="" Fax&=""
Contact&="David Lyon"</Purchasor Details>
>
> (I eliminated the new lines [which are disregardable in XML anyway] in
order to
> illustrate what you're doing).
>
> I was, silly me, reading it as
>
> <Purchasor Details
>   Company_Name&="Hotwire Business Systems"
>   Address_Line_1&="38^/332 Handford Road"
>   Address_Line_2&=""
>   Suburb_City&="Taigum"
>   Region_State&="QLD"
>   Postcode_ZIP&="4018"
>   Country&="Australia"
>   Telephone&=""
>   Fax&=""
>   Contact&="David Lyon">
> </Purchasor Details>
>
> (that is, I was reading it as attribute value pairs, if not as outright
elements).
>
> This being the case, the use of &, @, $ and # is perfectly legitimate.
>
> This being the case, it is one of the worst examples of XML I've ever
seen. The use
> of special characters in plain text (what you call structured text) to
indicate data typing
> is plain silly - why not use W3C XML Schema Part 2 Data Types?
>
> What I said about the pseudo ebxml declaration stands: it is not a
declaration, it is
> a Processing Instruction whose encoding remains unknown to all XML 1.0
conformant parsers.
>
> Finally, it is also non-parsable, because it uses white space in element
names (i.e.
> <Purchasor Details> is illegal in XML.
>
> Please don't pontificate on what parsers can or cannot do; as you say,
given a set
> of rules, parsers can do many wonderful things. The problem is that you're
breaking
> the rules for XML 1.0 parsers (no one is talking about generic text
parsers; certainly
> not me).
>
> ebXML is not supposed to replace or improve XML 1.0 (that's for W3C to
do) -- it's just
> supposed to use it correctly.
>
> Eduardo
>
> Eduardo Gutentag wrote:
> >
> > I agree with what Betty says below (except she probably meant & when
talking
> > about entities, rather than $); and would like to add that no existing
parser
> > (or any future conforming one) would be able to read the Processing
Instruction
> > you use <?ebxml Document, version#=1.0, encoding&="UTF-8"> and know that
your intention
> > is to use UTF-8 as encoding -- that is not an xml declaration; xml
declarations
> > start with the string "<?xml", not "<?ebxml".
> >
> > Let me put this another way: what you use looks suspiciously like XML,
but it
> > isn't. Of course you can use whatever you wish for your own purposes,
but please
> > be aware that it is a disservice to call it what it isn't, and present
it to the
> > unwary as interchangeable and standard.
> >
> > One thing is extensibility; another, quite different, is disregarding
the rules.
> >
> > Eduardo
> >
> > Betty Harvey wrote:
> > >
> > > On Thu, 31 May 2001, David Lyon wrote:
> > >
> > > > Betty,
> > > >
> > > > > The @ and the $ are not valid name characters in XML so they
cannot
> > > > > be used in either element or attribute names.
> > > >
> > > > Yes they can. XML can be made to do anything you want with it.
That's why
> > > > it's called "extensible", because it can be extended.
> > >
> > > @ and $ are not valid 'name' characters according to the W3C XML
> > > specification and and ISO 8876, SGML standard (XML's parent standard).
> > > In SGML you could extend the characters allowed in elements and
> > > attributes by modifying the SGML declaration.  XML has a static
> > > declaration.  In SGML you could do things like $elementname$ by
> > > modifying the declaration.
> > >
> > > SGML was extensible also but to cumbersome for the web.  Vendors
> > > had a very difficult time creating software to handle all the
> > > functionality and deviations allowed.  One of the goals of XML
> > > was to help developers the capability of developing interoperable
> > > code and to be used over the web.
> > >
> > > These are the valid names according to the W3C specification:
> > >
> > > [4]    NameChar    ::=    Letter | Digit | '.' | '-' | '_' | ':' |
> > > CombiningChar | Extender
> > > [5]    Name    ::=    (Letter | '_' | ':') (NameChar)*
> > > [6]    Names    ::=    Name (S Name)*
> > > [7]    Nmtoken    ::=    (NameChar)+
> > > [8]    Nmtokens    ::=    Nmtoken (S Nmtoken)*
> > >
> > > >
> > > > It's a flexible technology that is able to adapt to modern business
needs.
> > >
> > > True!  It isn't flexible on the naming conventions of elements,
> > > attributes and entities which are the building blocks of XML (both
> > > DTD's and Schema's).
> > >
> > > >
> > > > If you think the technology is static, then you should remember that
in the
> > > > old days, people said that you couldn't sail too far out to sea or
you'd
> > > > fall off the end of the earth.
> > > >
> > >
> > > It may not be static but you still have to color within the lines!
> > >
> > > > I do admit we are stretching the bounds of XML and make no apology
for it.
> > > > Actually the '$', '@', '#', '?' specifiers don't form part of the
element
> > > > name as you say they do. They simply denote the type of data that is
stored
> > > > so that the values can be safely read and converted to a different
data-type
> > > > if that is neccessary.
> > >
> > > It is invalid and any valid parser will reject it which means that if
> > > you cannot go outside the bounds of your world so therefore you
> > > are making your XML non-extensible.
> > >
> > > Standard tools will not work with non-standard XML.
> > >
> > > There is a serious problem with using the '$'.  This signifys an
> > > entity within a dataflow.  Any parser who sees the $ will be
> > > looking for the closing delimiter ';', i.e., $myentity;.  If
> > > you have <date$> it is going to confuse the parser beyond
> > > belief.
> > >
> > > >
> > > > Hence, Transaction_Amount can be expressed either as
> > > > Transaction_Amount&="34.56" (a string), or as
Transaction_Amount$=34.56 (a
> > > > currency field). They're both talking about the same data element,
which is
> > > > Transaction_Amount.
> > > >
> > >
> > > See above!  Can I suggest that you pick up James Clarks SP parser at
> > > http://www.jclark.com and try running your code through it.  James
> > > makes the best parser known to man and if it fails his parser it
> > > isn't valid.
> > >
> > > If you don't want to download his parser, it is a little hard to
> > > understand, then just try running some of your code in IE 5.0.
> > > IE 5.0 has a conforming and a validating parser.  If you don't
> > > reference the DTD then it is a conforming parser.
> > >
> > > > Thanks for your comments in any case.
> > > >
> > >
> > > Your welcome
> > >
> > > /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
> > > Betty Harvey                         | Phone: 410-787-9200 FAX: 9830
> > > Electronic Commerce Connection, Inc. |
> > > harvey@eccnet.com                    | Washington,DC SGML/XML Users
Grp
> > > URL:  http://www.eccnet.com          | http://www.eccnet.com/xmlug/
> > > /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\\/\/
> > >
> > > ------------------------------------------------------------------
> > > To unsubscribe from this elist send a message with the single word
> > > "unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org
> >
> > --
> > Eduardo Gutentag               |         e-mail: eduardo@eng.Sun.COM
> > XML Technology Center          |         Phone:  (650) 786-5498
> > Sun Microsystems Inc.          |         fax:    (650) 786-5727
> >
> > ------------------------------------------------------------------
> > To unsubscribe from this elist send a message with the single word
> > "unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org
>
> --
> Eduardo Gutentag               |         e-mail: eduardo@eng.Sun.COM
> XML Technology Center          |         Phone:  (650) 786-5498
> Sun Microsystems Inc.          |         fax:    (650) 786-5727
>