[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Notations
Fredrik Lindgren writes: > I always thought that the problem was about defining the > textual representations of values that should be understood > by an XML-processor and therefor used by who/what-ever writes > the document. There are really two problems: (1) what pattern of character strings are acceptable for content (attribute value or element content) and (2) how should those patterns be mapped to atomic types? > I don't see the point in just defining that an element is a > boolean value when this can be represented be (true/false), > (1/0) and (yes/no). Correct, both the 'type' of value and the 'encoding' of the value must be specified. In the world of HVAC, booleans are also (set/reset), (open/closed), (enabled/disabled), and (on/off). They all represent a two-state condition, although some are represented as two-value enumerations so the typical boolean operators cannot be applied. > The same problem arise when it comes to integers, "15" and "FF" > are both strings representing the same value. Almost :-). I've seen hex contants coded as 0xF, x'F', %x"F", I'm sure there are others. > To my knowledge both need to be parsed before they can be used. Yes, some kind of parsing is necessary, someplace! > This could be hidden by the programming language you use but the > XML-document should IMO be language independant. At some point a determination has to be made about what languages/patterns will be acceptable. Should 'fifteen' also be supported? What are the tradeoffs in parsing complexity vs. universal acceptance and language independance? If the source and target of some communication using an XML document are both humans, most of us are quite flexable (even if seeing some form or other makes us irritated). Give me 'fifteen' in French and I'll be just as lost as my parsers :-). > Regexp patterns might be a way to go to specify the allowed > representations, but the real need IMO is to specify what the > representation means, and for interoperability reasons agree > on standard representations for some set of data types. Coming to a concensious on this point is a good first step! This moves the discussion away from the "XML is only document markup and not a protocol" camp. I'm not in the "XML as a replacement for CORBA" camp, but my applications do need to interoperate with others I'm not writing (including humans), so I'm a little closer to the latter than the former. > I think it is important that such standard representations of > data types should be based on intended meaning and not computer > representation. To be a little simplistic, the "%4d" formatting specification in C and (I4) in FORTRAN is such a standard. It defines both the character string representation and how that is translated to and from an internal (machine specific) form. The examples I've seen are culturally biased in that they use Arabic numbers, but in theory it is localizable. >> <token id="name"> >> <set idref="namechar"/> >> <group optional="1" repeatable="1" disjunction="1"> > > What does the attribute value "1" represent? > >> <set idref="namechar"/> >> <set idref="digit"/> >> </group> >> </token> "1" means the group is optional, repeatable, etc. "0" means it is not optional, not repeatable, etc. I've tried to avoid design issues (which are mostly arbitrary), for example, is "<group optional='1'>" better or worse than "<group prop='optional'>"? Or should I say "<group optional='yes'>"? If we had a way to specify that the optional attribute is a boolean, that would be a help... :-) I would really like to say... <group optional> ... </group> But this is not support in the current standard. (At some point I would like to see support for attributes that don't have values, but that is for another thread. I intend to read the archives for this discussion.) Continuing the thread, James Tauber wrote: > Agreed. And to encourage reuse of notations, I am going to set up > a section on SCHEMA.NET as a repository for notation declarations. > John Cowan's are a great start. Any more. > > Let's actually put together some for some ISO8601 formats. Wheee! Count me in. :-) > > I would like to see the following syntax: > > <!ELEMENT OrderTime (#PCDATA) NDATA Iso8601_DateTime > > > when you can just have > > <!ELEMENT OrderTime (#PCDATA)> > <!ATTLIST OrderTime > notation NOTATION (Iso8601_DateTime) #FIXED "Iso8601_DateTime"> Can this be rolled along with parameters? Kinda like: <!ATTLIST TankLevel notation NOTATION (Iso8601_Float) #FIXED "Float(Precision,10,Scale,4)"> I've gotten confused about the format of the value of the notation attribute, isn't it supposed to be a URL or URN? Or perhaps this is only supposed to apply to the notation description? I'm guessing here... <!NOTATION Iso8601_Float PUBLIC "ISO 8601//NOTATION Float//EN"> The layers of standards and references to standards (that may or may not be working drafts of other standards) is driving me crazy! The XML spec says "associated system and/or public identifiers, to be used in interpreting the element to which the attribute is attached". From this I don't get the impression that is a URL or a URN, but "now for something completely different"... The idea that it can be "a reference into your schema or whatever you like" as Charles Reitzel wrote doesn't thrill me. It does bring a smile to my face when I think that I could simply say (which I know doesn't work)... <!NOTATION integer "%d"> All these clues are getting closer! Thanks everyone for helping me through this maze... Joel ------------------------------------------------------------------ Joel Bender Voice: 607-255-8880 Senior Programmer/Analyst FAX: 607-255-5377 Utilities Department 131 Humphreys Service Building Cornell University Ithaca, NY 14853-3701 ------------------------------------------------------------------ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|