RE: [xsl] schema-1 (was something about keys, a long while ago)

["Hunsberger, Peter" <Peter.Hunsberger@xxxxxxxxxx>]

>It's no fun at all if people take the opposite side of a debate from
>me and then make such plausible sounding arguments that there's a chance
>they might even be right...

Since you didn't explicitly quote back anything I sent to you I'll assume
it's some other response that you're objecting to and not apologize <g>...

>However I'm still not toally convinced. It seems to me relatively rare
>to have lots of different element names (would have been called eleemnt
>types in an earlier era) which all have the same schema type and all
>need to be processed in the same way. If they have the same internal
>structure and the same processing one wonders what's gained by calling
>them different names.

Well, all the elements have similar processing from an XSLt to HTML
formatting point of view.  But that's not the whole picture, the element
names also map to other objects residing in a universe just slightly outside
of the XSLt universe where the names are significant. Think of the XML as
being object glue (carefully avoiding any hint of SOAP) for a set of objects
that the XSLt doesn't really need to fully comprehend in order to do proper
presentation for.

The real point is, object name, may have little to do with the desired XSLt
behavior and expecting everyone to map by object name, instead of some other
object meta data limits the capabilities of XSLt.  Having said that, I
agree; at the moment, I only have the single case where this is a problem
and building a framework to handle general object meta data (on top of meta
data, i.e., XML, for data) may possibly result in the kind of recursive
black-hole that consumes standards committees for years on end.

>Given that you do have lost of xxx-date element names you have to
>_somewhere_ mapo them all to date. You say you don't want a long list in
>a template match  (or equivalenty one assumes a lot of individual
>templates each calling a named "date" template) but the information has
>to be somewhere, for example in a list of type assignments in the
>schema, this doesn't seem so much easier to maintain.

The schema is ultimately going to be the spot where the XML maintenance
issues come to rest.  In our case the XML will drive a lot more than some
XSLt (though presentation is a major portion of the problem).  I need to
have one spot to maintain type information and I certainly don't want to
have to map a Java object hierarchy explicitly in the XSLt and in the
schema!


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list