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

[Betty Harvey <ebxml@eccnet.eccnet.com>]

On Thu, 31 May 2001, Eduardo Gutentag wrote:

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

Eduardo, I was misreading it also.  I didn't see the the ">" and was
looking at Company_Name&="..." as an attribute and attribute value.

I agree wholeheartedly with everything you said.  I would also add one
more technical detail, the & cannot be used as a character.  The
XML parser sees the & as the beginning of an entity.  The ampsersand
would should be encoded as &.

Although I disagree with David L's response I will not escalate this
any further.

Betty

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