Thanks Michael. In my mind, for this spec, ease of implementation
trumps borrowing from existing specs if you cant in fact reuse existing
technology. e.g from what I can see <xsl:sequence select="xs:positiveInteger('5')"/> Has the advantage of borrowing from existing specs (xslt) but is overweighted by the complexity of implementing the parser for say "xs:positiveInteger('5')" Not only would one have to write a parser for <TYPE> '(' value ')' (not too hard) But because it is borrowing from existing specs the implication would be that we'd have to parse *anything* that could otherwise be in select="..." That would require a full blown XPATH 2.0 parser. Now of course we could refine the spec to limit the subset of XPATH 2.0 which is allowed to be in the select="" to only a small set of lexical elements. But then we're diverging from the original purpose of borrowing from existing specs which is that they are familiar, we dont have to re-document them, and they mean in this new spec fundamentally what they meant in the spec were borrowing from. Given that I'm going to suggest atomic values be represented as a new element like <atomicValue value="5" type="xs:positiveInteger"/>. But try to reuse the other suggested XSLT elements for documents, elements etc. All in a new namespace .. (because they are not actually the same thing as xsl: even if they are based on it). I'm a bit on the fence if atomic values should have the value as an attribute or body. Attributes make sense for small values like the above, but what a very common case of huge text. <atomicValue value="This is a huge block of text .... 1000000 lines later" type="xs:string" /> Gives me the impression the value should be in the body. <atomicValue type="xs:string">This is a huge block of text .... 1000000 lines later</atomicValue> Could always support both variants :( David A. Lee dlee@calldei.com http://www.calldei.com http://www.xmlsh.org 812-482-5224 Michael Kay wrote: A8BE77371C304F19BEF1624A7E68AB8C@Sealion" type="cite"> |