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
-----Original Message-----
From: John C Dumay
[mailto:]
Sent: Montag, 4. Februar
2002 12:38
To: 'Matthew Gertner'; 'CRAWFORD, Mark';
Subject: RE: [ubl-ndrsc] Elements vs.
attributes: discussion kickoff
Folks,
I tend
to agree. The only real use I can see for attributes of any kind is for genuine
meta-data as eluded by Matt. I prefer the use of attributes in schema when ever
possible as I find it much easier to map the elements to databases that need to
store the data contained the UBL instance documents. It certainly makes life
easier and less confusing. What we should be specifying then are the particular
instances when to use attributes, rather than creating a rule that satisfies an
80/20 situation, i.e.: ID, IDREF and xml:Lang as espoused by
Mark.
John
Dumay
-----Original Message-----
From: Matthew Gertner
[mailto:]
Sent: Monday, 4 February
2002 1:43 AM
To: 'CRAWFORD, Mark';
Subject: RE: [ubl-ndrsc] Elements vs.
attributes: discussion kickoff
My position on this is use attributes only for
document level information. This means that for the most part only built-in
document level attributes such as xml:lang, id and idref should be used and
elements should be used for all other transmitted data. My understanding
is there are parsing, ordering, and performance issues surrounded with
attributes. I also believe that by enforcing attributes at the document
level, we will provide clarity, avoid confusion, and enable better
structuring.
Here, here! My tendency would be to throw
down the gauntlet and ask: why ever use attributes? Most of the reasons raised
by Gunther are no longer relevant now that XSD lets elements do most of what
attributes can (i.e. be simple types, hold enumerations, have default values,
etc.). Using both elements and attributes is just confusing for the user,
developer and others, poorly supported by authoring environments, etc. I would
suggest that use of attributes be restricted to real metadata: identifiers,
links, etc. as proposed by Mark.
Matt
