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

[Philip Goatly <philip.goatly@bolero.net>]

Eduardo,

  Well said

"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."

if there is going to be any credibility the above is essential

Cheers, Phil

----- 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: Thursday, May 31, 2001 6:30 PM
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
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org
>