UBL Naming and Design Rules SC

 View Only

RE: [ubl-ndrsc] Elements vs. attributes: discussion kickoff

  • 1.  RE: [ubl-ndrsc] Elements vs. attributes: discussion kickoff

    Posted 02-05-2002 20:18
    Title: Message Hello all,   I think, we can use attributes in much more possibilities as for ID, IDRED and xml:lang only. I created some examples for it, because I can explain the advantages of attributes with that examples a little bit better.   I guess, we can use attributes for supplementary components especially. I will show this on my first example:    <xs:complexType name= AmountType_0p1 id= 000105 >   <xs:simpleContent>    <xs:extension base= cct:AmountContentType >     <xs:attribute name= amountCurrencyIdentificationCode type= cct:AmountCurrencyIdentificationCodeType />    </xs:extension>   </xs:simpleContent>  </xs:complexType>   The first example represents the core component type AmountType . The AmountType is derived by the content component AmountContentType . Therefore it is possible, the we can show the value as an element value of the AmountType. And the AmountType includes on supplementary component AmountCurrencyIdentificationCode . This supplementary component is derived by AmountCurrencyIdentificationCodeType and is represented as an attribute. The XML instance of this AmountType is represented as is follows:    <Amount_0p1 amountCurrencyIdentificationCode= EUR >33.34</Amount_0p1>   May be, the name of the attrribute is too long,. but I guess, this XML instance is for everyone readable too.   The next example shows the AmountType without any attribute:    <xs:complexType name= AmountType_0p2 >   <xs:sequence>    <xs:element name= AmountContent type= cct:AmountContentType />    <xs:element name= AmountCurrencyIdentificationCode type= cct:AmountCurrencyIdentificationCodeType />   </xs:sequence>  </xs:complexType>   I guess, it is more complicate for the parser as well as the user, if we using content and a childelement inside the complexType AmountType . Therefore it is necessary to create two childelements inside of AmountType . The XML instance will be then shown as the following example:    <Amount_0p2>   <AmountContent>33.34</AmountContent>   <AmountCurrencyIdentificationCode>EUR</AmountCurrencyIdentificationCode>  </Amount_0p2>   For describing Amount you need much more additional information. If you would like to describe huge documents based on that example, you need much more data as you use the first example. And I guess, that example is not better readable as the first example. I have recognized that the new version of DOM as well as the SAX parser parsing all attributes in a very fast and elegant way, faster as a lot of additional childelements.     The following example shows you, how you can create date-time elements in two different ways, if you using an attribute for describing the format:   If you would like to describe the dateTime format based on one built-in simpleType, you have to create the following schema:       <element name= DateTime_0p3 type= dateTime />   Otherwise, if you create a Date Time in a special format, based on ISO 8601, you can use the following complexType:    <complexType name= DateTimeType_0p1 >   <simpleContent>    <extension base= cct:DateTimeContentType >     <attribute name= dateTimeFormat type= cct:DateTimeFormatType />    </extension>   </simpleContent>  </complexType>   By the attribute, you can describe the specific format:    <DateTime_0p1 DateTimeFormat= YY-MM-DD >02-02-05</DateTime_0p1>   This XML instance represented the content in the same element. There is on attribute for describing the special format additionally. Therefore, there is no changing of the representation. That will be not so, if you describe the format by an additional child element, like the following esample:    <DateTime_0p2>   <DateTimeContent>02-02-05</DateTimeContent>   <DateTimeFormat>YY-MM-DD</DateTimeFormat>  </DateTime_0p2>   You need two child elements. One for the content and the other for the format description. That makes much more data and is not so easy understandable as the example before.     A problem is, if you have more than one supplementary components. For example codeType . Since as the values of each supplementary components do represent some processable data or codes respectively.   I give some examples:   A.)  <Code_0p1 codeListIdentifier= 1B codeListAgencyIdentifier= 28 codeListVersionIdentifier= 1 codeName= Special Code languageCode= en >ABCX</Code_0p1>   In the first example (A) are all supplementary components represented as attributes. The problem in that example is that will happen no direct relationship between codeName and languageCode. This must be necessary, because the languageCode is related to the codeName. B.)   <Code_0p2 CodeListAgencyIdentifier= 1B CodeListIdentifier= 28 CodeListVersionIdentfier= 1 >   <CodeContent>ABCX</CodeContent>   <CodeName languageCode= en >Special Code</CodeName>  </Code_0p2> In the second example (B) are the supplementary components shared in attributes and child elements. Supplementary components would like represented as attributes, if the data could be processably or coded information respectively. Supplementary components which represents user readable information represented as child elements. The content component is represented as child element, too. One expection have the attribute languageCode due to related to the readable name of the code it will be placed inside of the child element CodeName .   C.) <Code_0p3>   <CodeContent>ABCX</CodeContent>   <CodeListAgencyIdentifier>1B</CodeListAgencyIdentifier>   <CodeListIdentifier>28</CodeListIdentifier>   <CodeListVersionIdentifier>1</CodeListVersionIdentifier>   <CodeName>Special Code</CodeName>   <LanguageCode>us</LanguageCode>  </Code_0p3>   The last example the CodeType without any attributes. There are much more data and there is no relationship between CodeName and LanguageCode, too.   The attributes doesn't make the readability much more complicated. It help us, to build relationship in a very short and easy matter. The XML instances are much shorter and there are not so much hierachies for representing that data. That helps that the parsing of that structure is much more faster. And is helpful to map elements in an internal workflow or database respectively.   Regards,       Gunther