RE: [emergency-comment] Re: CAP and attribute-free encodings...

["Bob Wyman" <bob@wyman.us>]

Art Botterell wrote:
> Well, I'm not sure what makes attributes an 
> especially "important" part of XML... 
	Attributes are not only supported by XML 1.0 but there are
also a number of predefined "special attributes" that are defined as
supported in any XML 1.0 based format that doesn't explicitly prohibit
their use.
	For instance, XML 1.0 supports the special attributes:
	* xml:space, which MAY be attached to an element to signal an
intention that in that element, white space should be preserved by
applications. See XML 1.0 section 2.10 "White Space Handling". 
	* xml:lang, which MAY be inserted in documents to specify the
language used in the contents and attribute values of any element in
an XML document. See XML 1.0 section 2.12 "Language Identification". 
	(Note: Although the special attributes *look* like they are
"namespaced" attributes, this is not the case. xml:space and xml:lang
were defined before the namespace document appeared and are thus
"special attributes" that require no namespace declaration.)
	Since the CAP specification is silent on the subject of these
special attributes, the assumption of one reading the specification
should be that they are supported.

> Your "ambiguity" point strikes me as well taken, but 
> since the conventions of namespacing are relatively new 
> and best known within the XML community, we left that 
> particular problem over for later refinement.
	Please understand that I did not propose that you use
namespaces. (That is an entirely different discussion.) All I proposed
was that rather than introduce a new "type" (the string-encoded
name/value pair) that you use the facilities provided by XML to
require that "code_types" be included in an element distinct from the
"value" of something like a geocode. For instance, I'm proposing:

	<geocode>
	  <codetype>fips6</codetype>
	  <value>987987</value>
	</geocode>

rather than what is currently specified:

	<geocode>fips6=98787</geocode>

	This does not require namespaces to implement and is
semantically equivalent to the current CAP specification. It is,
however, much more in keeping with the intentions and common usage of
XML while allowing for greater expressiveness in the XML Schema.
(There is an implied requirement that code_type be provided. The XML
Schema can explicitly require that code_type be provided if you use
two elements but it cannot express the requirement if you use the
current method of overloading a string type.) It should also be noted
that using this "two element" approach, the complexity of
implementations would be reduced. Rather than having to follow the XML
parsing pass with a special "name/value pair" parsing phase, an
implementer would be able to rely on just XML parsing if the "two
element" approach that I propose is used. Making code simpler is a
good thing...

> However, the elements where this approach is used are 
> ones intended to permit the inclusion of 
> application-specific codes that aren't essential to 
> the function of CAP and that, for the most part, we 
> have no way of foreseeing at standards-setting-time.
	But, at "standards-setting-time" you have already anticipated
that the values for some fields should be tagged with a code_type and,
as mentioned elsewhere, there is an implied (but not stated)
requirement that code_type must be present. Thus, you have "foreseen"
a requirement for code_type even if you haven't defined what all the
code types are. Additionally, you've defined a system that implies
that these application-specific codes can be structured into two
components: 1) The code_type, and 2) The value or code itself. Given
that you've accepted these assumptions and requirements, it makes
sense to support them explicitly in the specification and XML Schema
and to do so in a manner which conforms to normal XML usage...

		bob wyman