[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: UBL Elements corresponding to XSD Datatypes
Reading http://www.oasis-open.org/committees/ubl/ndrsc/current/p-stuhec-datetime-05.doc, I agreed very much with the conclusion that it's important to create elements corresponding one-to-one with the xsd datatypes, but why give those elements holding the text values different names from those assigned by the XML Schema? Of course noone wants explosions like <IssueDateTime>, <IssueDate>, <IssueYear>,<IssueYearMonth>,<IssueMonth> and<IssueMonthDay>. The obvious conclusion is that child elements are necessary; so what should they be named? We've done some work here to rationalize various code lists published by ISO and SI. You're invited to review this work at http://www.hypergrove.com/Publications/Symbols.html.... this list of symbols was then directly translated into XML elements, which you can review at http://www.hypergrove.com/Publications/DC200DTD.zip, created for the purpose of marking up flowing text. As examples, <ft2>12000</ft2> is the markup for 12,000 sqft; <edtz>8:00</edtz> is the markup for 8am EDT; <usd>450.00</usd> is the markup for $450.00 USD; <en>some text string</en> is the markup for English text; and <boolean>0</boolean> is the markup for text conforming to an XSD datatype. We find this approach to be incredibly easy to be used by markup designers, web programmers, and functional staff who incidentally need to view XML. We use the same approach suggested in the UBL paper, applied on a consistent basis. Further, we are using vocabularies already internationally standardized. I do recognize that this approach may conflict with some UBL naming rules, but I still request that you consider the many benefits of using the names of the datatypes as element names themselves. The whole set I'd suggest you'd look at is: "anySimpleType|anyURI|base64Binary|boolean|byte|date|dateTime|decimal|double|dur ation|float|gDay| gMonth|gMonthDay|gYear|gYearMonth|hexBinary|int|integer|language|long|negativeIn teger| nonNegativeInteger|nonPositiveInteger|normalizedString|positiveInteger|short|str ing|time|token| unsignedByte|unsignedInt|unsignedLong|unsignedShort"> Second, I request that you consider minimally allowing the text equivalent of a conforming ISO date at the same time as the conforming ISO date -- this wasn't clear in the paper. Such as: <Issued> <date>2003-12-21</date> <en>December 12, 2003</en> </Issued> Finally, I request that you consider requirements such as <Issued> <on><Date><gDate/><en/></Date></on> <after><Date><gDate/><en/></Date></after> <before><Date><gDate/><en/></Date> </before> <notAfter><Date><gDate/><en/></Date></notAfter> <notBefore><Date><gDate/><en/></Date></notBefore> </Issued> Thank you, John McClure
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]