|
Yes, the supplementary
component does provide additional information. However, there is no
requirement for it to appear in the instance. What really troubles me is
that we have a previously agreed to schema module done in partnership with OAG
and CEFACT, and now we want to change it with no real business case for doing
so. That is the same problem I have with some of the other changes being
made this week - done without a real business case for doing so, nor the
opportunity to fully consider all of the impacts of the change.
Mark
Mark,
Coming at this from another angle, it seems to me
that the supplementary components are meant to be seen in the instance; they
provide additional information about the content. Is this correct? Taking
advantage of the facets of an xsd:built-in datatype is a different
issue.
With
the 'format' supplementary component, we could see something
like:
<ShipDate format="YYYY-MM-DD" >2004-03-05</ShipDate>
in
the instance.
Mike
Grimley
Michael,
You did bring up the
issue of facet restriction at the F2F. I
have talked to Gunther, and
Jessica and I did a quick test
with some code and it does
work. You are right that Format per se is not a built-in facet, but pattern is. We can use pattern in the
derived datatype to support the supplementary component of format.
That was the basis of the work that Gunther
and Garret did.
Code
follows:
<?xml version="1.0" encoding="UTF-8"?>
< xs:schema
xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:element name="ShipDate" type="OrderDate"/>
<xs:element name="ShipDateNew" type="OrderDateNew"/>
<xs:simpleType name="OrderDate">
<xs:restriction base="xs:date"/>
</xs:simpleType>
<xs:simpleType name="OrderDateNew">
<xs:restriction base="OrderDate">
<xs:enumeration value="2004-06-09"/>
<xs:enumeration value="2004-06-15"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
Valid
<?xml version="1.0" encoding="UTF-8"?>
< ShipDate
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation ="C:\Documents and
Settings\jglace\Desktop\Standards\RestrictTest.xsd">2004-03-05</ShipDate>
Invalid
<?xml version="1.0" encoding="UTF-8"?>
< ShipDateNew
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation ="C:\Documents and
Settings\jglace\Desktop\Standards\RestrictTest.xsd">2004-06-30</ShipDateNew>
Valid- if you assume Spy has implemented correctly, this proves that a
restricted built-in that is again further restricted will have the
additional constraints enforced.
<?xml version="1.0" encoding="UTF-8"?>
< ShipDateNew
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation ="C:\Documents and
Settings\jglace\Desktop\Standards\RestrictTest.xsd">2004-06-09</ShipDateNew>
Mark
I misspoke. The facets are
available, but some were under the impression that 'Format' was a facet of
these types and it is not.
Mark,
The decision was
made, in Washington, to add the 'Format' supplementary component
after it was determined that none of the attributes/facets of
the xsd:built-in datatypes would be available due to 'our' types being
defined as an empty Restriction of the built-in
type.
Mike
Grimley
Michael,
We initially agreed with
your recommendations, but after further discussion we agreed that we
would be better off to stay with the CCT schema module as jointly
agreed to with OAG and UN/CEFACT. That schema modules leverage
the xsd:built-in datatypes where appropriate and will give us much
better credibility in the XML community at large. Having said
that, I understand that the selective group is making changes to
Washington decisions so I can't really say what the final answer
is. However, I will tell you that unnecessary deviations
from joint agreements with other standards bodies will ensure that UBL
will completely stand alone in its implementation of CCTS,
and will ensure that its support base will be
limited.
Mark
Ooooh, I seem to remember that
the NDR discussion in Washington was just the other way
round and that the group disagreed with my 'simple' CCTS
approach.
Now, I'm confused.
Stephen: help
Michael
Greetings,
As mentioned in a previous email, and not
included below, the
latest CCT schema still has 'DateTime', 'Indicator' and 'Numeric'
types defined as simple types (with a *Restriction* on the built
in type).
I believe we had agreed
in Washington that they would be redefined to conform to the CCTS.
That is, the required supplementary component 'Format' would be
added to the definition of each.
I wasn't able to make yesterday's meeting (until the end,
anyway) and Jon has made it very clear that that is where the
decisions are made; however, this involves CCTS conformance and,
if I am not mistaken, the decision was made in joint session with
Tim and Steve on the phone, so there was good representation of
all concerned SCs.
Thank You,
Mike
Grimley
|