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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: alternate enums in XML Schema

[ Lists Home | Date Index | Thread Index ]
  • From: Curt Arnold <CurtA@techie.com>
  • To: xml-dev@xml.org
  • Date: Sun, 07 May 2000 14:20:10 -0500

I thought the broad outline of what I proposed in the "international
booleans" thread in late 1999 would have addressed the original issue
with minimal additional complexity (that is when an mapping from a list
of literals to a lexical acceptible to the base type is sufficient). 
http://lists.w3.org/Archives/Public/www-xml-schema-comments/1999OctDec/0022.html,
http://lists.w3.org/Archives/Public/www-xml-schema-comments/1999OctDec/0023.html. 
However, the schema WG did not apparently the need was sufficient or the
solution simple enough.

In the case where of date formats where the transform is more
complicated and needs some type of behavior, either you need to add some
minimal string manipulation language to XML Schema, such as regex
substitution, or the ability to invoke objects.  This can't be
accomplished through appinfo since the transform is essential to
determining whether the document is valid or not.

I could see something like

<simpleType name="USDate" base="date">
	<!--  this transforms matches MM/DD/YYYY and converts to YYYY-MM-DD  
		parenthesis identify groups that can be referenced by \n where n is
their
                order  -->
	<transform match="([0-1][0-9])/([0-3][0-9])/([0-9]*)"
value="\3-\1-\2"/>
</simpleType>

Multiple transform elements could be specified, the first that matches
would be effective.  The transforms would be performed before any facet
evaluation is performed.

With these two facilities, Schema would be much more usable for enhanced
validation of existing document systems whose representation of data
does not conform with datatypes lexical representation.  I haven't
reviewed it, but if any of the lexical representations in Microsoft's
XML Data-Reduced are not consistent with XML Schema datatypes, that
would be a very strong motivation to add sufficient transform support so
that XDR can be put out of its misery.

Unfortunately, I see quite a few critical issues that need to be
addressed and I'm going to be spending a lot of late nights writing
comments to meet the last call date of next weekend.

I can't see the next step as being Candidate Recommendation, there seem
to me just too many open issues.

***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS