1614 2005-07-15 00:15:43 +0000 please spell out all defaults explicitly 2005-09-27 08:41:15 +0000 1 1 1 Unclassified XPath / XQuery / XSLT Formal Semantics 1.0 Last Call drafts PC Windows 2000 CLOSED FIXED P2 normal --- 1 fred.zemke simeon public-qt-comments oldest_to_newest 4690 0 fred.zemke 2005-07-15 00:15:43 +0000 2.4 The [XPath/XQuery] type system Since this is a purely formal language, not exposed to users, there is no point in defining any defaults. Instead, making every declaration totally explicit is to be preferred as the clearest. By that principle, optionality should be used only for cases where missing syntax corresponds to a missing characteristic of the defined type, rather than a defaulted characteristic. Adopting this principle would eliminate the need for the reader to chase down the defaults (which is really hard to do in the current document, and I am not sure they are always there). Instead, the normalization and type expansion rules should supply all defaults explicitly. For example, the normalization rule for item() would be [item()]sequencetype == ( element of type xs:anyType | attribute | text | document { ( text | element of type xs:anyType | comment | processing-instruction )* } | xdt:anyAtomicType ) In the case of attribute, the normalization rule in 3.5.4 "SequenceType matching" currently is misleading, precisely because it does not spell out the default. One might think that the default type of an attribute node is xs:anyType (on the strength of the statement in 2.4.4 "Top level definitions" that "When the type derivation is omitted, the type derives by restriction from xs:anyType..."). However, xs:anySimpleType is more appropriate, so the normalization rule should be [attribute()]sequencetype == attribute of type xs:anySimpleType This example shows that errors in the specification can be uncovered by simply attempting to spell out all the defaults explicitly in the rules. 5053 1 simeon 2005-07-20 23:48:55 +0000 I essentially agree with the intent. We should notably make sure we go over the document to see if we find other problems than the one you mention. Having defaults everywhere will make the examples unnecessarily unreadable though. I would like to propose an intermediate compromise which would be: * define default only for use in examples * make sure that none the formal rules use any default Any comment on that approach? - Jerome 5146 2 mrys 2005-07-22 16:48:51 +0000 The WG discussed this issue and asked the editors to improve the understanding of defaults in the document while taking your feedback and the discussion within the working group into account. Feel free to close the bug if you agree with the resolution. If you disagree, feel free to reopen it.