Re: [libsmi] re-engineering xml file to smi doc. with xsl
Hi!
Mark> If I remeber currectly, you can use xsl to transform one XML Mark> into another XML. Since SMI is not in an XML like format, I Mark> don't think it is possible.
XSL can transform to XML, but also to plain text and further optional formats. (<xsl:output method="text|xml|html|..."/>)
Mark> Anyway, what reason is there to retransform an XML to SMI?
I did not try to do such conversations, since we already have smidump. Maybe, XSLT 1.0 is missing some programatic features. I don't know.
However, I agree with awk that it would be `cool' to do this with XSLT. Some people might bring forward the argument that programming and adapting XSL snippets is easier and more flexible than traditional program code. I'm not sure whether I share this argument *completely*, but however I think it's cool to use XSL for prototyping conversions.
-frank
I agree that XSL and XML are grate tools, and personaly I believe that the evolotion of SMI should be into an XML format. Of course when MIBs will be written in XML there will no loner be a need for the libsmi ;-)
However, right now I'm so glad that I can get an XML out of an SMI, and work on the XML with all the variety of tools that exists in the XML world, that I fail to see any real reason for anybody to go the other way around. Do I miss anything, something that I'm not aware of?
The only "real world" XSL tranformation that I can think of right now is converting the output of smidump to XHTML in order to display it in a browser with syntax coloring, links for imports and probably more. The first step for accomplishing this IMHO is to define a scheme or dtd for the XML generated by smidump. I don't remember seeing any in the libsmi files,. I'm attaching an XML schema file generated by automatic tool from the RMON2 XML, It probably needs refinement but it might serve as a starting point for a complete schema.
Mark.
----- Original Message ----- From: "Frank Strauss" strauss@ibr.cs.tu-bs.de To: "Mark Kaplun" markk5@bezeqint.net Cc: awkkock@yahoo.com; libsmi@ibr.cs.tu-bs.de Sent: Wednesday, May 22, 2002 12:06 PM Subject: Re: [libsmi] re-engineering xml file to smi doc. with xsl
Hi!
Mark> If I remeber currectly, you can use xsl to transform one XML Mark> into another XML. Since SMI is not in an XML like format, I Mark> don't think it is possible.
XSL can transform to XML, but also to plain text and further optional formats. (<xsl:output method="text|xml|html|..."/>)
Mark> Anyway, what reason is there to retransform an XML to SMI?
I did not try to do such conversations, since we already have smidump. Maybe, XSLT 1.0 is missing some programatic features. I don't know.
However, I agree with awk that it would be `cool' to do this with XSLT. Some people might bring forward the argument that programming and adapting XSL snippets is easier and more flexible than traditional program code. I'm not sure whether I share this argument *completely*, but however I think it's cool to use XSL for prototyping conversions.
-frank
!! This message is brought to you via the `libsmi' mailing list. !! Please do not reply to this message to unsubscribe. To unsubscribe or
adjust
!! your settings, send a mail message to libsmi-request@ibr.cs.tu-bs.de !! or look at https://www.ibr.cs.tu-bs.de/mailman/listinfo/libsmi.
Hi!
Mark> I agree that XSL and XML are grate tools, and personaly I Mark> believe that the evolotion of SMI should be into an XML Mark> format. Of course when MIBs will be written in XML there will no Mark> loner be a need for the libsmi ;-)
Mark> However, right now I'm so glad that I can get an XML out of an Mark> SMI, and work on the XML with all the variety of tools that Mark> exists in the XML world, that I fail to see any real reason for Mark> anybody to go the other way around. Do I miss anything, Mark> something that I'm not aware of?
Other people might say, we already have the SMI for more than a decade, why should we change things that worked not too bad in the past?! Switching to a new technology must bring reasonable *advantages*. It's not enough to say the existing technology is not better than the proposed new technology.
Mark> The only "real world" XSL tranformation that I can think of Mark> right now is converting the output of smidump to XHTML in order Mark> to display it in a browser with syntax coloring, links for Mark> imports and probably more.
Do you know about the MIB repository at the SimpleWeb?!
http://www.simpleweb.org/ietf/mibs/
Mark> The first step for accomplishing this IMHO is to define a scheme Mark> or dtd for the XML generated by smidump. I don't remember seeing Mark> any in the libsmi files,.
We have made slight attempts to write a DTD (draft-irtf-nmrg-smi-xml-00.txt) and later an XML Schema, but we did not follow this approach til the end. However, I agree that, *if* people would put all eggs in the XML basket, standardized XML MIB representation and MIB data representation should be the first step.
Mark> I'm attaching an XML schema file generated by automatic tool Mark> from the RMON2 XML, It probably needs refinement but it might Mark> serve as a starting point for a complete schema.
Feel free to go on... ;-)
-frank
some relevant links on this subject: www.trl.ibm.com/projects/xml/xss4j/docs/axt-readme.html cheers, Abdella
Frank Strauss wrote:
Hi!
Mark> I agree that XSL and XML are grate tools, and personaly I Mark> believe that the evolotion of SMI should be into an XML Mark> format. Of course when MIBs will be written in XML there will no Mark> loner be a need for the libsmi ;-)
Mark> However, right now I'm so glad that I can get an XML out of an Mark> SMI, and work on the XML with all the variety of tools that Mark> exists in the XML world, that I fail to see any real reason for Mark> anybody to go the other way around. Do I miss anything, Mark> something that I'm not aware of?
Other people might say, we already have the SMI for more than a decade, why should we change things that worked not too bad in the past?! Switching to a new technology must bring reasonable *advantages*. It's not enough to say the existing technology is not better than the proposed new technology.
Mark> The only "real world" XSL tranformation that I can think of Mark> right now is converting the output of smidump to XHTML in order Mark> to display it in a browser with syntax coloring, links for Mark> imports and probably more.
Do you know about the MIB repository at the SimpleWeb?!
http://www.simpleweb.org/ietf/mibs/Mark> The first step for accomplishing this IMHO is to define a scheme Mark> or dtd for the XML generated by smidump. I don't remember seeing Mark> any in the libsmi files,.
We have made slight attempts to write a DTD (draft-irtf-nmrg-smi-xml-00.txt) and later an XML Schema, but we did not follow this approach til the end. However, I agree that, *if* people would put all eggs in the XML basket, standardized XML MIB representation and MIB data representation should be the first step.
Mark> I'm attaching an XML schema file generated by automatic tool Mark> from the RMON2 XML, It probably needs refinement but it might Mark> serve as a starting point for a complete schema.
Feel free to go on... ;-)
-frank
!! This message is brought to you via the `libsmi' mailing list. !! Please do not reply to this message to unsubscribe. To unsubscribe or adjust !! your settings, send a mail message to libsmi-request@ibr.cs.tu-bs.de !! or look at https://www.ibr.cs.tu-bs.de/mailman/listinfo/libsmi.
Abdella Battou writes:
Abdella> some relevant links on this subject: Abdella> www.trl.ibm.com/projects/xml/xss4j/docs/axt-readme.html Abdella> cheers, Abdella
Let us not confuse the SNMP data definition language and the SNMP protocol.
The SNMP protocol is indeed a proper application of ASN.1 and you can of course replace the BER encoding with an XML encoding. It is probably a matter of taste whether this makes sense or not. XML encodings certainly won't be much smaller and given the message size constraints of SNMP over UDP (the default transport mapping), one can make arguments that this does not buy us than much.
The SMI data definition language is not pure ASN.1 - it is an extended subset. The smidump -f xml output is consistent with the concepts of the SMI language and I doubt that using a generic ASN.1 to XML translator would produce reasonable results. (If it is a correct ASN.1 implementation, it won't be able to parse the input and stop.)
The smidump -f xml output is really intended to allow programs which need access to SMI definitions and which already have XML parsers but no SMI parsers can get access to what they need easily. Many exiting commercial tools read intermediate file formats such as the mosy format which is nowhere really defined. The smidump -f xml output was intended to replace this immediate format with a well defined XML format.
Recently, Torsten Klie has written the smidump -f xsl output format which produces an XML schema derived from the MIB modules. This translation happens at the data definition / schema layer which allows to encode management information in XML according to the generated schema. In case people see benefits in replacing the BER encoding of SNMP, using the schemas to derive XML encodings is IMHO much more useful than just replacing BER with XER. But again, we have many SNMP protocol implementations these days that interoperate at the protocol level and the question remains to be answered whether changing the protocol really improves the way we manage networks.
For me, the real dilemma is not really a technology issue. Right now, I am trying to write an application which can create port based VLANs on various bridges and so far I have had to implement 3 different ways to do this for bridges from 3 different vendors. So the real problem I have is that the good stuff is in proprietary data definitions and I doubt that changing the protocols or data definition languages to use XML will improve this situation in any way.
/js
----- Original Message ----- From: "Frank Strauss" strauss@ibr.cs.tu-bs.de To: "Mark Kaplun" markk5@bezeqint.net Cc: awkkock@yahoo.com; libsmi@ibr.cs.tu-bs.de Sent: Tuesday, May 28, 2002 11:52 AM Subject: Re: [libsmi] re-engineering xml file to smi doc. with xsl
Hi!
Mark> I agree that XSL and XML are grate tools, and personaly I Mark> believe that the evolotion of SMI should be into an XML Mark> format. Of course when MIBs will be written in XML there will no Mark> loner be a need for the libsmi ;-)
Mark> However, right now I'm so glad that I can get an XML out of an Mark> SMI, and work on the XML with all the variety of tools that Mark> exists in the XML world, that I fail to see any real reason for Mark> anybody to go the other way around. Do I miss anything, Mark> something that I'm not aware of?
Other people might say, we already have the SMI for more than a decade, why should we change things that worked not too bad in the past?! Switching to a new technology must bring reasonable *advantages*. It's not enough to say the existing technology is not better than the proposed new technology.
Mark> The only "real world" XSL tranformation that I can think of Mark> right now is converting the output of smidump to XHTML in order Mark> to display it in a browser with syntax coloring, links for Mark> imports and probably more.
Do you know about the MIB repository at the SimpleWeb?!
http://www.simpleweb.org/ietf/mibs/
If they use XSL on the server side, and can contibute it, it will be (IMHO) a nice addition to the libsmi, and a partial answer to the original question.
Mark> The first step for accomplishing this IMHO is to define a scheme Mark> or dtd for the XML generated by smidump. I don't remember seeing Mark> any in the libsmi files,.
We have made slight attempts to write a DTD (draft-irtf-nmrg-smi-xml-00.txt) and later an XML Schema, but we did not follow this approach til the end. However, I agree that, *if* people would put all eggs in the XML basket, standardized XML MIB representation and MIB data representation should be the first step.
Mark> I'm attaching an XML schema file generated by automatic tool Mark> from the RMON2 XML, It probably needs refinement but it might Mark> serve as a starting point for a complete schema.
Feel free to go on... ;-)
I will given the time, and some kind of commitment that whoever will change the smidump -f xml code in future will have to test the resulting XML to be complient to the schema, otherwise there is no point of doing it.
Mark.
One point that I have forgot earlier, is that currently you can not generate the original MIB files from the XML because the XML do not include the comments :-)
Mark.
participants (4)
-
Abdella Battou -
Frank Strauss -
Juergen Schoenwaelder -
Mark Kaplun