OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-comment message

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