[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Carmelo's Post on Gathering Discretionary Implementation Issues
At 26 Jun 2000 21:12 -0400, atman wrote: ... > Just now as I was writing up the xsl:attribute element, I noticed another > such discretionary area, e.g., the xmlns prefix for a created attribute > when the namespace URI is declared and no namespace prefix is stipulated, the > processor can make one of sorts. Right or wrong, I wanted to note this, > just as more obvious things like generate-id() behavior where some proces- > sors always make the saME id in teh same stylesheet/input instance circum- > stances but are not required to do so by the spec. Cf., the current occas- The generate-id() behaviour is not a conformance issue since the Recommendation notes: An implementation is under no obligation to generate the same identifiers each time a document is transformed. It would be a conformance issue if the Recommendation had required that identifiers were the same each time or if, as in so many other places, the Recommendation said not doing it was an error but also allowed alternative behaviour. It might be a compatibility issue, if you ignore the caveats in the Recommendation and actually depend on a processor doing that, but I think that that level of compatibility is out of scope. > sion prompting this post, I'd like it if I could hop online and note it when It is one thing to be able to pop online and note it, but it is another thing to have to pop online just to see if anyone else has noted anything new. I, for one, don't feel that I have the bandwidth to take timely notice of things that appear only on a web page, so I would rather that discussion points are posted to this list, just as they have been in recent days, Posting them to this list also allows discussion about whether or not something really is a facet of XSLT that allows discretionary error recovery. Adding that sort of threaded discussion to a CGI script adds a whole lot of complexity! Of course there still needs to be a summary of the discretionary error recovery areas. In the absence of a CGI script, I will volunteer to collate the identified areas of discretionary error recovery in advance of next week's telephone call. It seems to me that each identified area needs: - An identifier, since the information will be eventually marked up and used to control processing - XSLT Recommendation section reference - Excerpt of or reference to defining text in the Recommendation - A question, for use with the eventual "rendition control instance", that can be answered either yes, signal the error, or no, perform the alternate behaviour. For example, for a different point noted in section 7.1.3: Creating nodes other than text nodes during the instantiation of the content of the xsl:attribute element; implementations may either signal the error or ignore the offending nodes. the question might be: Signal error when creating other than text nodes in content of xsl:attribute? > it is fresh as there was another discretionary area I noticed a few days ago > and had no easy way to report it--but tonight I wanted to procrastinate > from writing the book and also participate somewhat in this auguste group. > > So, XSLT 7.1.3 notes > > XSLT processors may make use of the prefix of the QName specified in the name attribute when selecting the prefix used for outputting the created attribute as XML; however, they are not required to do so and, if the prefix is xmlns, they must not do so. Thus, although it is not an error to do: > > -- > And I thought this might qualify as a discretionary area, nad a reason to > raise teh point that a regular, easy, input point for such issues would be > fortuitous to gather as many as possible. It seems to me that using or changing attribute prefixes is discretionary behaviour. As long as the resulting XML is well-formed and conforms to the namespaces recommendation, I don't think there's anything that can be said about it. Any following application that relies on certain namespace prefixes in the transformation's output is itself broken, but that's not our problem. Using or not using certain prefixes doesn't seem to be discretionary error recovery, which is what I've been talking about so far. What are we concerned about identifying as discretionary? > In the spirit of offering to help, I'll write the HTML page for doing > so, such that--I'm sure--someone could go one step further and automate > the annotation of the output to an HTML page-- I only know enough/have > time to get the CGI script to send the email to . . . somewhere, logically > for starters, this list. I would say that you can just as easily send mail to the list yourself as have a CGI script do it, except that you report that you are having trouble sending mail! Remember, identifying discretionary behaviour/error recovery is really just a sidebar to the main activity with test cases and documentation, and I expect that there'll be plenty of XSLT stylesheet writing, not just CGI script writing, happening once we get to that stage. 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