W3C home > Mailing lists > Public > public-diselect-editors@w3.org > April to June 2005

Re: XSLT Literal Result Element

From: Rhys Lewis <rhys.lewis@volantis.com>
Date: Fri, 13 May 2005 11:56:35 +0100
Message-ID: <D18551A6C7EA6241B960D4909EB75DF5023091B5@squid.volantis-uk>
To: <mf@w3.org>
Cc: <public-diselect-editors@w3.org>


First, thanks very much for taking the time to comment on the last call working draft of Content Selection for Device Independence.

DIWG has now had a chance to review your 3 substantive comments. This mail documents our responses.

Would you please review the responses and let us know if you feel they are appropriate? As you know, we need to document formally agreement by the originators of comments.


"The functions could be defined in the same style as the XPath2/XQuery Functions and Operators spec [2], i.e. make them namespaced? "di-cssmq-width" -> "sel:cssmq-width". That would allow XPath2 engines to use the functions without any ambiguity about where they come from."

DIWG has decided to decline this comment.

We've debated the question of using XPath 2 or XPath 1 on many occasions during the development of the specification. Indeed we have even had internal versions that were based on XPath 2. We would have preferred to allow the host language to decide which version of XPath it preferred to use. Comments on an earlier working draft showed that that was, unfortunately, disallowed.

In the end there were two reasons for sticking with XPath 1, despite the advantages of namespace support and data typing offered in XPath 2. The first was the availability of implementations. This is particularly important where the specification is implemented on client mobile devices. The second was compatibility with XForms. Although not apparent from the specification alone, DISelect forms part of a language profile being developed by DIWG. This profile depends on XHTML 2 and XForms, so compatibility is important for the DI group's use of the specification.

" There are many typos in the spec, mostly missing spaces following code or anchor tag."

DIWG has decided to accept this comment.

We will review and correct the formatting of the entire document. Thanks for pointing this out.

"Section 5 is confusing because one doesn't know the structure of each element until 5.10. I would suggest examples in each section. Or even better, something like:

   5.1 Overview
   5.2 Conditional Processing
     5.2.1 if
     5.2.2 select (describe when/otherwise here)
   5.3 Options
     5.3.1 idreplace
     5.3.2 process
     5.3.3 required"

DIWG has decided to accept this comment.

The primary issue is that the internal structure of the <select> element is not apparent at the start of section 5. While we accept that there can be an improvement here we would prefer that all of the elements be defined in sections that appear at the same nesting level in the TOC to make them easy to spot.

Rather than reorganising the section, we will add an introductory description of the structure of the elements and describe their typical use in the Overview section (5.1). 


Best wishes

Rhys Lewis, chair DIWG
Received on Friday, 13 May 2005 10:52:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:37:03 UTC