[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: To get things started.... Data formats
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC