MHonArc v2.5.2 -->
ubl-ndrsc message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: Re: [ubl-ndrsc] Handcrafted Schema for Core Component Types
I like the idea of making the simple type go directly to a built-in XSD
simple type if possible, so I prefer the features that make versions 2
and 4 below unique. There's no reason to increase the number of CCT
simple types through trivial derivation.
But regarding the use of standardized namespaces for language and linking...
I looked up the semantics of xml:lang [1], and it turns out I was wrong:
the language indicated in this attribute applies to "the contents and
attribute values of any element". So it's okay to use it to apply to
the supplementary component for the code name. Therefore, versions 1
and 2 below are okay with respect to xml:lang. We should consider
whether it's possible to use xml:lang on *all* the places where normally
a languageID would go -- for example, doesn't the spreadsheet currently
require Language elements to be created in some locations, with
semantics that are consistent with xml:lang? Do we break our rule about
"no attributes except supp components" and make these attributes on
their object classes instead?
I'm a little more dubious about using XLink for listURI. I have a few
reasons for this:
- XLink should be used when you have a "traversal semantic"; that is,
the link is supposed to be routinely "followed" somewhere. I don't
think this is the purpose of the listURI attribute.
- XLink is awkward to use if you have multiple attributes that have a
"traversal semantic"; you either have to use XLink for only one of them,
or you have to change your structure to use elements instead of
attributes. The code list supplementary components include both
listSchemeURI and listURI. I don't see exactly why listSchemeURI is
supposed to be the link's role and listURI is supposed to be its remote
resource; more likely, this seems like a multi-ended link.
- It hurts to say this, because I was the primary editor of XLink :-),
but... It doesn't buy us anything currently to add the XLink overhead to
UBL. If we really want to follow the value of listURI or listSchemeURI
as a link, we now have the ability to know that they are of type anyURI
(why does the table say "string"?...).
So I would prefer that listURI, listSchemeURI, etc. remain UBL-specific
and be given a type of xs:anyURI.
Eve
[1] http://www.w3.org/TR/REC-xml#sec-lang-tag
Stuhec, Gunther wrote:
> Hello all,
>
> I attached a zip-file with four different versions of handcrafted core component types.
>
> 1st Version
> ========
> I defined in the first version (CoreComponentTypes_1.xsd) for every CCTs a tuple existing of a simpleType and contentType. Example:
>
> <xsd:simpleType name="AmountContent" id="000106">
> <xsd:restriction base="xsd:decimal"/>
> </xsd:simpleType>
> <xsd:complexType name="AmountType" id="000105">
> <xsd:simpleContent>
> <xsd:extension base="cct:AmountContent">
> <xsd:attribute name="currencyID" type="xsd:token" use="required" id="000107"/>
> <xsd:attribute name="codeListVersionID" type="xsd:token" use="optional" default="2002"/>
> <xsd:attributeGroup ref="cct:commonAttributes"/>
> </xsd:extension>
> </xsd:simpleContent>
> </xsd:complexType>
>
> Additionally, it using the standardized namespaces for language and linking. It will be used the attribute xml:lang instead of languageID and xlink:href, xlink:role and xlink:type for the linking to another locations.
>
> 2nd Version
> =========
> In the second version do the CCTs based on the built-in datatypes directly. Therefore, they do not have a tuple of simpleType for the Content and complexType for the CCTs itself.
> Example:
>
> <xsd:complexType name="AmountType" id="000105">
> <xsd:simpleContent>
> <xsd:extension base="xsd:decimal">
> <xsd:attribute name="currencyID" type="xsd:token" use="required" id="000107"/>
> <xsd:attribute name="codeListVersionID" type="xsd:token" use="optional" default="2002"/>
> <xsd:attributeGroup ref="cct:commonAttributes"/>
> </xsd:extension>
> </xsd:simpleContent>
> </xsd:complexType>
>
> This version does have the (W3C) standardized definitions for language and linking in a different namespace, too.
>
> 3rd Version
> =========
> The third version is the same as the 1st version but do not have standardized definitions for language and linking.
>
> 4th Version
> =========
> The fourth version is the same as the 2nd version but do not have standardized definitions for language and linking.
>
> We should discuss, which kind of handcrafted xml schema for CCTs should be the best one.
>
> Kind regards,
>
> Gunther
>
>
> <<CoreComponents.zip>>
--
Eve Maler +1 781 442 3190
Sun Microsystems cell +1 781 354 9441
Web Technologies and Standards eve.maler @ sun.com
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC