[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [emergency-comment] Re: CAP and attribute-free encodings...
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]