[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: New list of discretionary items
At 9 Aug 2000 15:29 -0400, G. Ken Holman wrote: > At 00/08/09 14:08 -0400, David_Marston@lotus.com wrote: > >Tony, thanks for composing the update. You noted: > > >The additional items don't always fit well with the idea of recasted > > >the text of the Recommendations as a question that can be answered > > >by 'yes' or 'no'. > > > >I think that yes/no is too much to hope for. It would be very nice if > >we could get the answers down to a range of keywords. Conceptually, > >this would be like "What languages do you support for sorting?". I knew that just yes/no questions was too much to ask for, but I did them that way to get some discussion going. > However, can we not scope our *first* version of the test suite to be as > simple as possible, perhaps even deferring cultural sort schemes? As Ken says, the first version should be as simple as possible just so we have some hope of finishing on time. I would dearly like to handle language-specific sorting and numbering, but I fear that we have too much else to do. I also think that we should solicit language-specific test cases from the people who actually speak those languages. ... > >Since the tests > >need to cover so much of the text of the W3C recommendations, the > >additional work to mark discretionary and vague areas will be > >minor. > > I'm not sure what you mean here. Lots of minute pieces of the Recommendations need to be individually identified. > I can take on the action item of seeding an XML version of the > Recommendation with ID anchors so they can be referenced by IDREFs (much > like I did for the summary of the XML 1.0 Recommendation in the XML > Conformance Suite, except for the entire document and not just section > heads). David, have you yet documented your requirements for granularity > for the citations already made by the Lotus tests? Putting IDs in a copies of the Recommendations is a lot of work that is not reusable for XSLT 1.1 or an XPath 1.1. Each item in the list of discretionary behaviours that I sent last night has an XPointer identifying the element containing the relevant text from the Recommendations. Those XPointers could and should be extended to identify the relevant spans of characters within the identified elements. We could use XPointers to identify all significant portions of the Recommendations and do away with needing custom versions of the Recommendations. Actually, one way to make the XPointers would be add markup delimiting and identifying the spans of text to a copy of a Recommendation and then run a stylesheet that calculated an XPointer into the undoctored Recommendation corresponding to each of the marked up spans in the doctored version of the Recommendation. After all, I generated the XPointers in last night's list using a grep-like stylesheet run on the XML version of the Recommendations. At least some of the XPointers would be reusable across versions of the Recommendations, and the XPointers could be made more robust by using XPointers that started at elements with IDs or that started at divs with specified titles instead of the navigating from the root as is done so far. Regards, Tony Graham ====================================================================== Tony Graham mailto:tgraham@mulberrytech.com Mulberry Technologies, Inc. http://www.mulberrytech.com 17 West Jefferson Street Direct Phone: 301/315-9632 Suite 207 Phone: 301/315-9631 Rockville, MD 20850 Fax: 301/315-8285 ---------------------------------------------------------------------- Mulberry Technologies: A Consultancy Specializing in SGML and XML ======================================================================
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC