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

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

Betty,

I appreciate where you're coming from from a technical perspective.
Basically you're advocating using a layered approach to building software
whereby present/future ebXML software must be built upon all the layers of
specifications that are available from organisations as W3C and so forth.
I'm familiar with the argument, and on the surface it seems reasonable
enough.

In practice however, it leads to bad things occuring as you rightly point
out:

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

So why not fix the problem ?

Why perpetuate it forever more ?

Why can't ebXML be better than previous attempts at XML ?

In fact, from a software engineering what you are saying about parsers and
'$' symbols is fundimentally incorrect.

You need to restudy how parsers work and what they are able to do.

Parsers are actually fed lexical rules which are an 'input'. The '$'
character is treated no differently than other characters. If you provide
the correct lexical rules, any sort of structured text can be 'parsed'. Your
statements are therefore a complete misrepresentation of the capabilities of
'parser' software.

Overall, what you are advocating is software that is so complex and
inefficient that it hardly even works. Demonstrated by the fact that if you
give it a '$' symbol then it gets "confused".

ebXML needs to move away from these flaky software engineering approaches
that you talk about and focus on reliability, security and traceability.
Otherwise most companies will stay with their fax machines or their EDI
systems.

At least a fax machine doesn't get confused if you accidently write a dollar
symbol on the page!

Take care

David Lyon


----- Original Message -----
From: Betty Harvey <ebxml@eccnet.eccnet.com>
To: David Lyon <djlyon@one.net.au>
Cc: <ebxml-core@lists.ebxml.org>; <ebxml-dev@lists.ebxml.org>
Sent: Thursday, May 31, 2001 10:32 PM
Subject: Re: To get things started.... Data formats


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