[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [emergency] Re: Attributes vs Elements (from Gary)
>From Gary... -----Forwarded Message----- > From: "Ham, Gary A" <hamg@BATTELLE.ORG> > To: 'R. Allen Wyke' <emtc@nc.rr.com>, "Weltman, Jerry" <jerry.weltman@ieminc.com> > Cc: 'RCarlton@eteam.com' <RCarlton@eteam.com>, EM TC <emergency@lists.oasis-open.org> > Subject: RE: [emergency] Re: Attributes vs Elements > Date: 08 May 2003 15:08:46 -0400 > > > Allen, > > Please pass to the whole committee. My outbounds are still bouncing > > The following was cut and pasted from the DOJ schema: > > <xsd:attribute name='Reliability' type='xsd:decimal' /> > <xsd:element name='Reliability' type='xsd:decimal' /> > <xsd:attribute name='ReportedDate' type='xsd:date' /> > <xsd:element name='ReportedDate' type='xsd:date' /> > <xsd:attribute name='ReportingOrganization' type='xsd:string' /> > <xsd:element name='ReportingOrganization' type='xsd:string' /> > <xsd:attribute name='ReportingPerson' type='xsd:string' /> > <xsd:element name='ReportingPerson' type='xsd:string' /> > <xsd:attribute name='ReportingPersonRole' type='xsd:string' /> > <xsd:element name='ReportingPersonRole' type='xsd:string' /> > > Sometimes they are defining the use of the SAME INFORMATION STRUCTURE as an > attribute AND element. > Does anyone know the rationale? > > R/S Gary Ham > > > > > -----Original Message----- > From: R. Allen Wyke [mailto:emtc@nc.rr.com] > Sent: Thursday, May 08, 2003 2:10 PM > To: Weltman, Jerry > Cc: 'RCarlton@eteam.com'; EM TC > Subject: [emergency] Re: Attributes vs Elements > > > Oh boy - you have just stepped into one of the biggest debates of all times. > However, you are right - it is appropriate for us to discuss this and to do > so within the larger audience of the EM TC. I will take what you have, and > run with it (fully realizing that I am sure it will stimulate some responses > :) > > The objective of this discussion will be to formalize some *basic* > guidelines we should all adhere to for any XML schemas we develop. I think > it is best we do not set hard and fast rules and that we provide some wiggle > room for each SC, but we do need to be consistent in at least some fashion. > I will include the outcome in the guidelines document I am working on. > > For the context of this debate and to start the discussion, let me list the > basis of how I came to a recommendation: > > 1. There is no single and always correct answer. > > 2. You will be hard pressed to find a definitive human definition of > "element" or "attribute", in the context of XML, to provide a single answer > to this question. However, it is generally accepted that attributes are > metadata about its containing element with some implied inheritance in any > subsequent child elements. > > 3. The 6th design goal of the original XML Recommendation > http://www.w3.org/TR/REC-xml#sec-origin-goals) states that "XML documents > should be human-legible and reasonably clear." > > 4. There is a technical argument within XML Schema Part 2: Datatypes (around > internationalization), to keep human-readable text out of attribute values. > Under the xsd:string datatype (http://www.w3.org/TR/xmlschema-2#string), it > says: > > NOTE: Many human languages have writing systems that require child elements > for control of aspects such as bidirectional formating or ruby annotation > (see [Ruby] and Section 8.2.4 Overriding the bidirectional > algorithm: the BDO element of [HTML 4.01]). Thus, string, as a simple type > that can contain only characters but not child elements, is often not > suitable for representing text. In such situations, a complex type that > allows mixed content should be considered. For more information, see Section > 5.5 Any Element, Any Attribute of [XML Schema Language: Part 2 Primer]. > > In not so many words, it says "don't use attributes for human-readable > text". You are not able to include elements, for further description, in > attribute values and things like hard returns are problematic from a > programming standpoint (not too mention a long attribute value violates #3 > above). > > 5. From a programming standpoint, accessing elements vs. attributes isn't > very different if you use a good parser/processor. > > Based on these, I recommend we do the following as part of our guidelines. > > -------------------------- > Any and all schema developed by the EM TC and its SCs SHOULD: > > 1. in general practice separate metadata into attributes. > > 2. make every effort to keep documents human-legible and reasonably clear as > specified in the Origin and Goals > (http://www.w3.org/TR/REC-xml#sec-origin-goals) of the "Extensible Markup > Language (XML) 1.0 (Second Edition)". > -------------------------- > > Ok, the gasoline has been poured. I am sure someone will now strike the > match :) > > Allen > > On Wed, 2003-05-07 at 18:32, Weltman, Jerry wrote: > > Allen and Rick, > > > > During the Notifications and Messaging SC a couple of weeks ago, I > > brought up the issue that we could be using attributes for some of the > > data instead of elements. The response was overwhelming that we should > > not be using attributes, which is fine by me. But I am wondering > > whether there should be some debate among the TC in general on this > > issue since it seems like we would prefer that all of the TC's XML > > structures have a similar style. > > > > Or perhaps I am missing something. Is there something about the work > > we are doing that makes attribute-free XML structures an obvious > > common goal? > > > Jerry > -- > R. Allen Wyke > Chair, Emergency Management TC > emtc@nc.rr.com > http://www.oasis-open.org/committees/emergency > > -- R. Allen Wyke Chair, Emergency Management TC emtc@nc.rr.com http://www.oasis-open.org/committees/emergency
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]