Namespace problem with TXSDateTime elements

Hi!

I need to pass an TXSDateTime element in a different namespace than 
http://www.w3.org/2001/XMLSchema.

The generated code from the WSDL importer looks something like this:
...
    PriceListVersionDate = TXSDate;      { 
"http://www.dkma.dk/medicinecard/xml.schema/2008.01.01"[GblSmpl] }
...
    property PriceListVersionDate:                 PriceListVersionDate 
Index (IS_REF) read FPriceListVersionDate write FPriceListVersionDate;
...
    RemClassRegistry.RegisterXSInfo(TypeInfo(PriceListVersionDate), 
'http://www.dkma.dk/medicinecard/xml.schema/2008.01.01', 
'PriceListVersionDate');

but still the code in the SOAP body looks something like this:
<SOAP-ENV:Envelope 
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
...
<xsd:PriceListVersionDate>2006-02-15</xsd:PriceListVersionDate>
...

where it should have read
<xsd:PriceListVersionDate 
xmlns="http://www.dkma.dk/medicinecard/xml.schema/2008.01.01">2006-
02-15</PriceListVersionDate>

How can I work around this issue?

Regards,
Erik 

Hello Erik,

Thanks for the report. These TXSxxxx types always lag a little behind -
unfortunately:( - because they are the exception: they following the path of
complexTypes - because they are TRemotable-derived - but they act as simple
types. I should know better since each time we've added some support, these
types cause a little trouble. For example, when we added attribute support
for simple types, we left out these fake-simple types that show up as
complex type from an RTTI point of view. Several other areas had the same
issue simply because we have to treat them specially.

I'll need to investigate this issue but one workaround might be to switch to
a TDateTime. Of course, TDateTime is rather limited when it comes to XML
dateTime but if the data you're passing falls within the TDateTime range, it
might work.

I'll post my findings as soon as time allows me to investigate.

Cheers,

Bruneau.

I tried the TDateTime aproach but unfortunately it didn't switch the 
namespace. It only caused the value to formatted a little different 
(2006-02-15T01:00:00.000+01:00 instead of 2006-02-15).

I hope you can find a working solution...

/Erik

"Jean-Marie Babet" <bbabet@borland.com> skrev i en meddelelse 
news:479feae0@newsgroups.borland.com...
> Hello Erik,
>
> Thanks for the report. These TXSxxxx types always lag a little behind -
> unfortunately:( - because they are the exception: they following the path 
> of
> complexTypes - because they are TRemotable-derived - but they act as 
> simple
> types. I should know better since each time we've added some support, 
> these
> types cause a little trouble. For example, when we added attribute support
> for simple types, we left out these fake-simple types that show up as
> complex type from an RTTI point of view. Several other areas had the same
> issue simply because we have to treat them specially.
>
> I'll need to investigate this issue but one workaround might be to switch 
> to
> a TDateTime. Of course, TDateTime is rather limited when it comes to XML
> dateTime but if the data you're passing falls within the TDateTime range, 
> it
> might work.
>
> I'll post my findings as soon as time allows me to investigate.
>
> Cheers,
>
> Bruneau.
>
> 

Tans for the update. I'll research this today!

Cheers,

Bruneau.

Hello,

I spent some time researching this and it's an importer problem.

I created two global elements in namespace A(type_ns0). One of type
'dateTime' and one of the type 'integer. In namespace B(type_ns1), I created
a complex type with elements that refer to the global elements.

    <s:schema elementFormDefault="qualified"
targetNamespace="urn:type_ns0">
      <s:element name="RefDate" type="s:dateTime"/>
      <s:element name="RefInt" type="s:integer"/>
    </s:schema>

    <s:schema elementFormDefault="qualified"
targetNamespace="urn:type_ns1">
      <s:import namespace="urn:type_ns0" />
      <s:complexType name="TComplexType">
        <s:sequence>
          <s:element ref="s2:RefDate" />
          <s:element ref="s2:RefInt" />
        </s:sequence>
      </s:complexType>
    </s:schema>


I then created a WebService that echoes TComplexType. The importer generates
the following:


  RefDate         = TXSDateTime;      { "urn:type_ns0"[GblElm] }
  RefInt          =  type Int64;      { "urn:type_ns0"[GblElm] }


  //
************************************************************************ //
  // XML       : TComplexType, global, <complexType>
  // Namespace : urn:type_ns1
  //
************************************************************************ //
  TComplexType = class(TRemotable)
  published
    property RefDate: RefDate  Index (IS_REF) read FRefDate write FRefDate;
    property RefInt:  RefInt   Index (IS_REF) read FRefInt write FRefInt;
  end;

initialization
  RemClassRegistry.RegisterXSInfo(TypeInfo(RefDate), 'urn:type_ns0',
'RefDate');
  RemClassRegistry.RegisterXSInfo(TypeInfo(RefInt), 'urn:type_ns0',
'RefInt');

(I'm leaving out the non-relevant portion from the file generated by the
importer).

The problem is obvious right away. RefDate iw a *weak* alias of TXSDateTime.
So from an RTTI point of view, 'RefDate' is identical to TXSDateTime. Even
though it's registered to a specified namespace, that Registration call will
fail because the underlying RTTI is that of TXSDateTime and the latter is
already registered. RefInt, on the other hand, is a *strong* alias of Int64.
This means that its RTTI is distinct and the registration will succeed.

So as expected, the above generates the following XML:

    <echoRemotableWithRef xmlns="http://tempuri.org/">
      <param>
        <xsd:RefDate>2008-01-30T14:50:48.132-08:00</xsd:RefDate>
        <RefInt xmlns="urn:type_ns0">0</RefInt>
      </param>
    </echoRemotableWithRef>


IOW 'RefInt' is in the correct namspace while 'RefDate' is not in the
namespace associated with the type RefDate but rather with that associated
with the TXSDateTime type.

The fix is to make RefDate a strong alias. Since TXSDateTime is a class, you
can use strong alias syntax. Instead, you have to derive.  IOW:

Replace this line:

  RefDate         = TXSDateTime;      { "urn:type_ns0"[GblElm] }

with

  RefDate = class(TXSDateTime) end;


And that's it. Now the XML generated is:

    <echoRemotableWithRef xmlns="http://tempuri.org/">
      <param>
        <RefDate
xmlns="urn:type_ns0">2008-01-30T14:59:24.094-08:00</RefDate>
        <RefInt xmlns="urn:type_ns0">0</RefInt>
      </param>
    </echoRemotableWithRef>


So, now that I understand the issue, I'll update the importer and upload it
to CodeCentral as soon as time allows. In the mean time, please updated the
binding generated by the importer to use derivation instead of a weak alias
for cases of TXSxxxxx types. Please let me know if the above does not match
what you're seeing.

Cheers,

Bruneau.