OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xslt-conformance message

[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