OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

[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]