Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Sun Microsystems

Sun Releases Open Source XACML Language 157

Posted by Hemos from the building-the-tools dept.
LowneWulf writes "An InternetNews.com article mentions that the OASIS standards group today ratified the Extensible Access Control Markup Language 1.0 specification. But even better, Sun Microsystems Labs has backed this up with an open-source version in Java on Sourceforge."
This discussion has been archived. No new comments can be posted.

Sun Releases Open Source XACML Language More

Sun Releases Open Source XACML Language

Comments Filter:

  • wow (Score:4, Funny)

    by unterderbrucke ( 628741 ) <unterderbrucke@yahoo.com> on Tuesday February 18, 2003 @06:08PM (#5329455)
    YAUML (Yet Another Useless Markup Language) should become more commonly used around here.

    • Re:wow (Score:1)

      by Mas3 ( 620769 )
      sounds like the name of an aztec god ...

      --
      Stefan

      DevCounter [berlios.de] - An open, free & independent developer pool
      created to help developers find other developers, help, testers and new project members.

  • How? (Score:5, Insightful)

    by JanusFury ( 452699 ) <kevin...gadd@@@gmail...com> on Tuesday February 18, 2003 @06:09PM (#5329460) Homepage Journal
    How can a language be open source? A language doesn't need source; it's a syntax. Compilers need source, not languages. 'Open Source Language' sounds like more hype to me. I may be stupid, but I don't know of any truly open source implementations of the Java that this 'Open Source Language' is in (Last I checked, Sun had a pretty strict licensing scheme going for Java implementations)

    • "Open source" reference implementation (Score:5, Insightful)

      by yerricde ( 125198 ) on Tuesday February 18, 2003 @06:17PM (#5329576) Homepage Journal

      How can a language be open source?

      I consider a language to be "open source" if it has a reference implementation available to the public as OSI Certified(TM) open source software [opensource.org].

      • That would be a compiler/reference implementation.

        A language can definitely be 'Open', but the term 'Open Source' has absolutely no meaning when attached to a language.

        'Open Source English'.

        That makes absolutely no sense. My point is not related to how useful or good this language is, I'm just annoyed at this example of Sun's generally confusing and strange marketing.

        • 'Open Source English'. That makes absolutely no sense.

          The PICK operating system had a database query language called English [wikipedia.org], a dialect of SQL. I'd consider the English programming language (not the English natural language in which this comment is written) an "open-source language" if one of the major free databases (MySQL, PostgreSQL, SAP DB, etc) introduced PICK interoperability through support for English queries.

          If you're worried about my use of "open-source language" to refer to "computer language with a widely used open-source implementation", don't worry too much. Such "overloading" is common in computer jargon.

        • OT, trolling, flamebait, whatever:

          Sun is quite good at this sort of bullshit wordplay (though far from being the only ones). They really like to throw around the woprd "standard", conflating quite different meanings of the word to suggest that what they offer is not proprietary. For example, J2EE is "standards based", but only in the sense that a sole company (Sun) can define the standard.

          They refer to the use of some XML syntax as using a standard, but as the W3C is not a true standards body ( as, say ISO is), XML is only a standard by general consensus.

          Sometimes they refer to a something that's actually defined by a standards body. But that's rare.

          • That's just plain wrong. Enter Java Community Process [jcp.org]and check for yourself the list of participants. Like IBM, BEA, Apache, Apple, etc. That is if you like to know what you are talking before posting.

            From the home page: "Java Community Process is the way the Java platform evolves. Its an open organization of international Java developers and licensees whose charter is to develop and revise Java technology specifications, reference implementations, and technology compatibility kits. Both Java technology and the JCP were originally created by Sun Microsystems, however, the JCP has evolved from the informal process that Sun used beginning in 1995, to a formalized process overseen by representatives from many organizations across the Java community."

            • True. But who has final, legal say? If there is a disagreement between the JCP and Sun Inc, who wins?

              Basically, Sun gets to pick people's brains, and see what major vendors are willing to support. But Sun gets the final say. Notice how all the copyright and trademark notices for Java(tm) refer to Sun, not the JCP or some other independant organization.

    • Re:How? (Score:3, Interesting)

      by TummyX ( 84871 )

      A language doesn't need source; it's a syntax

      Uh. And grammar.


      Compilers need source, not languages. 'Open Source Language' sounds like more hype to me

      Well open source language simply means a langauge where the compiler is OSS. It doesn't make less sense than saying "Perl is open source".

      • Re:How? (Score:1)

        by cyba ( 25058 )
        > > A language doesn't need source; it's a syntax
        > Uh. And grammar.

        Wrong. Grammar simply describes language's syntax.
        • >>> A language doesn't need source; it's a syntax
          >> Uh. And grammar.
          >Wrong. Grammar simply describes language's syntax.

          I thought that the grammar described the language's semantics. It's been a while since I took either Algorithms or Programming Languages, but that's what I recall.
    • I assume that they mean that Sun tools that support the language are in Java and are OS, not the language itself.
    • You mean like Ada used to be, Java is etc etc etc..

      How is this getting modded up in a place where Java is constantly criticised for being closed source. If a company creates a document it owns the copyright on that document, if it trademarks a name it owns that name. If you create a language that has the same syntax with the same meaning then you are breaking those "rights".

      UNLESS you can create a Clean Room implementation ala the original IBM Bios clones. And who would want to do that for a language.

      • If you create a language that has the same syntax with the same meaning then you are breaking those "rights".

        If I don't call it Java(TM) brand then I'm not infringing Sun's Java mark. Stating that something "interoperates with programs that use Java(TM) technology" is fair use of Sun's technology.

        Likewise, if I write my own spec without using any of Sun's expression, I break no copyright. There is currently no U.S. copyright on facts (1y7 USC 102(b) [cornell.edu]; Feist v. Rural [cornell.edu]).

        UNLESS you can create a Clean Room implementation ala the original IBM Bios clones.

        The dirty/clean process used to write the clone of IBM PC BIOS involved one "dirty" team that turned the BIOS code and its observed behavior into a specification and another "clean" team that turned the specification into a computer program. It was designed to defeat any accusation of access to the original work, without which there is no copying and thus no infringement. Anybody who has never seen Sun code and works only from the published specification is already "clean".

    • Today Open Source is like any buzzword we have come across in history. In the 80-ies AI was the hot thing. "Everything" was to be AI and everyone wanted to be associated with the word, but eventually the hype backfired and today no one cares. Now that Open Source is a mainstream word it is only a matter of time before this buzzword gets outdated too.
    • The project page [sourceforge.net] explicitely says:

      This is an open source implementation of the OASIS XACML standard, written in the Java (TM) programming language.

      It doesn't say that the standard is open source. It doesn't say that Java is open source. It says the implementation in Java is open source.

      Of course, it doesn't prevent from creating close-source implementations of the same standard. But XACML standard specs by themselves are openly available [oasis-open.org] from OASIS.

  • Jee-aah! Another language! That's great, because we can never have too many of these. I was just thinking to myself, "Gee, I wish I had another markup language to learn".

    (obl: karma to burn)

    • Umm, the entire purpose of XML is to define custom vocabularies for specific applications. You don't have to learn it, it's for computers to use to communicate with one another in a heterogenous environment. Sun has provided an API and implementation for you to use.

      Do you have a learning disability?

  • DRM? (Score:1, Offtopic)

    by yerricde ( 125198 )

    What application does this language have in digital restrictions management of copyrighted works?

    • None (Score:3, Insightful)

      by M.C. Hampster ( 541262 )

      Not everything is about DRM. Move along.

      • Spare the poor sod, he was trying to get some karma. It was a decent attempt, but it would have been even better if it had the word "Linux" or "GNU" somewhere along with "DRM". "RIAA" and "M$" also have mystical effects over moderators.

  • I'd hardley say useless (Score:5, Insightful)

    by Anonymous Coward on Tuesday February 18, 2003 @06:16PM (#5329567)
    there are real reasons why this new markup language is needed. It is intended for complex distributed processes that cross several application domains. the common example is a travel agent, who needs to book travel plans for a customer. The booking includes, flights, trains, cars, hotels and motels. Given the complexity of booking that many items in one single transaction across multiple booking systems, you need a common authentication mechanism. What would you prefer? Everyone write their own authen scheme, which may be secure, but will take a couple months to implement. Multiply by the number of companies the travel agent connects to book reservations.

    there are those who disagree, but those whose jobs require complexity, it is a step towards easier integration. Microsoft should just go with the architecture Oasis has laid out for ebXML and dump their piece of junk which originally had no concept of coreography.

    • Sounds like what XML was supposed to do in the first place.

      Hey I renember you people... I gave you a project and you gave me all these reasons why it will work...

      It didn't work. But you gave me twice as many reasons why the next try it will work. So you tried again.

      Eventually it was obvious that the world was just not ready for every arctitecture to seamlesly integrate with others.

      I'm not touching it!

      I'm going back to post it notes, you guys call me when you figure it all out.
      • No, no, no. Humor aside, XML was never supposed to behave as an access control system. It WAS intended to be a self-describing and self-validating way of encapsulating lots of different kinds of data. It's succeeded, is popular because of that fact, and XACML is an example of how you can even store entitlement logic in XML. Now, with XACML you can implement that same logic not only in Java but also C, C#, PHP, ASP, VB, Perl, and anything else you desire because the rules are stored in a language-independant and platform-independant format. THAT's the main benefit, and Sun should be given credit where credit is due.
    • It is intended for complex distributed processes that cross several application domains.

      Yes, and so are the other 3,142 languages that came out last month and the 2,675 languages from the month before that. Don't get me started on the 15,476 .NET languages...I'll pass out!

  • Sun Microsystems Labs has backed this up with an open-source version in Java

    I got excited for second, incorrectly reading this as.. Sun Microsystems Labs has backed this up with an open-source version of Java

    • Re:Got really excited (Score:1, Informative)

      by Anonymous Coward
      Most of the source code to the Java language is available. The only thing lacking is the VM. Before anyone says that the VM is java, a majority of the language is implemented IN java and is freely available.

  • Such prosaic names and acronyms... (Score:3, Funny)

    by Consul ( 119169 ) on Tuesday February 18, 2003 @06:23PM (#5329652) Journal
    The subject submits its query to the entity protecting the resource (e.g. file system, web server). This entity is called a Policy Enforcement Point (PEP). The PEP forms a request (using the XACML request language) ... (snip)

    They should have called its language PEP Talk. ;-)

  • XACML is (Score:3, Funny)

    by WetCat ( 558132 ) on Tuesday February 18, 2003 @06:23PM (#5329653)
    just l33t version of HackML - a language
    made specially for hackers!

  • Interesting twist, the sourceforge bit (Score:3, Insightful)

    by jaiger ( 166690 ) on Tuesday February 18, 2003 @06:25PM (#5329676) Homepage Journal
    First, synchronize watches - how long before JBOSS integrates this?

    Now on to more serious commentary. This story is interesting in that Sun might actually be "getting it". Sure they've been saying "we get it" for some time but that crappy Sun license...that's just what we needed, YACL (Yet Another Community License).

    This project is actually on Sourceforge, and with a BSD-looking license no less!! I like what I'm seeing, Sun.

    -joe

  • RTFP people (Score:5, Informative)

    by f00zbll ( 526151 ) on Tuesday February 18, 2003 @06:26PM (#5329701)
    For those who are too damn lazy to read what the language does and why Sun wrote a reference implementation.

    * One standard access control policy language can replace dozens of application-specific languages

    * Administrators save time and money because they don't need to rewrite their policies in many different languages

    * Developers save time and money because they don't have to invent new policy languages and write code to support them; they can reuse existing code

    * Good tools for writing and managing XACML policies will be developed, since they can be used with many applications

    * XACML is flexible enough to accommodate most access control policy needs and extensible so that new requirements can be supported

    * One XACML policy can cover many resources; this helps avoid inconsistent policies on different resources

    * XACML allows one policy to refer to another; this is important for large organizations, for instance, a site-specific policy may refer to a company-wide policy and a country-specific policy.

    Before someone else rants about copy protection, find out what it is before you start typing. I'm guitly of it in the past, but this is a useful language will real benefits.

    • One standard access control policy language can replace dozens of application-specific languages

      But what is an "access control policy language"? Is it the language used to write ACLs on files and folders, or is it a language used to write copyright management information as defined in 17 USC 1202 [cornell.edu]?

    • I dont agree with these reasons. Why should peple have to rewrite their security implementations just because SUN came up with a new, unnecessry markup. One of the beauties of XML is so many different language bindings exist. If the various aspects of my security use XML to communicate then I can write them in just about any language I please.

      Secondly what do people feel about having a system like this in the public domain? I am not an advocate of security through obscurity but with this system the bad guys will have a very good understanding of how the whole system works. Should an implemenatation be exposed then multiple systems become vunerable.
      • One of the beauties of XML is so many different language bindings exist.

        That XML is a lingua franca is frequently asserted but can't be proved. The reason is that XML has no (or more strictly, very limited) semantics.

        To say that your application can "understand" XML because it can use the DOM API doesn't mean that it can interpret XACML, or any other XML "ontology". You might just as well argue that you can understand Danish because you can parse the "å" character.

        All you are saying when you assert that XML applications can be written in any language is that the semantics of XACML (or whatever) can be mapped to various programming languages.

        This feature is shared by any machine-readable language, many of which are arguably better at representing XACML semantics than XML.

        • To say that your application can "understand" XML because it can use the DOM API doesn't mean that it can interpret XACML, or any other XML "ontology". You might just as well argue that you can understand Danish because you can parse the "å" character.
          XML is a data storage format, well-suited to data that has heirarchy and structure. The DOM API could well be said to "understand" XML in the sense that it knows what it needs to know in order to directly translate an XML document into a data structure.

          Of course it doesn't necessarily know what to do from there -- because that's domain specific knowledge. But no general API treats that, and that's why the analogy presented seems a little bit off to me.... talking about "understanding" in any case when it comes to modern computing technology isn't right.
          • Of course it doesn't necessarily know what to do from there -- because that's domain specific knowledge

            Only if you consider such general things as variables and operators to be domain-specific.

            "General APIs" are probably not a useful concept here. It's possible to view DOM (but not SAX) as an AST, but this just serves to show how limited the grammar of XML is in relation to a conventional language.
    • One standard access control policy language can replace dozens of application-specific languages...

      One XACML policy can cover many resources...

      One language to rule them all...

  • Sun is providing Java programmers for easily accessing and mutating this new ACL standard. This has value since there are so many fucking Java programmers you morons.

  • Unfortunately not everyone "gets it" (Score:5, Insightful)

    by binaryDigit ( 557647 ) on Tuesday February 18, 2003 @06:31PM (#5329765)
    The requirement of having robust access control (beyond simple enter your name and password) is not very common outside the corp. world. So those who've not had to deal in that code would not fully understand how big of a deal that this markup language CAN be (assuming it's adopted, robust, etc, etc). This is definitely one of those areas where "everybody rolls their own", or worse, they dumb down their access control to fit things like directory services and the ilk, that were never intended to do what this is trying to.

    Funny how in many posts this has degenerated into either "we don't need no more stinkin languages" or "Sun/Java sucks, yadda, yadda".

    • Re:Unfortunately not everyone "gets it" (Score:5, Insightful)

      by afidel ( 530433 ) on Tuesday February 18, 2003 @06:56PM (#5330062)
      Oh this is SO true, for instance my last employer was GE, within GE there are probably at least 100 different authentication domains (this is being conservative, there are probably several hundred) in the last couple of years they have tried to unite a large % of these under an SSO policy, only problem is to even get your SSO information you might have to travel across 3-4 domains. For instance to get mine I had to get inside the firewall with a vpn client, acess a controlled page with a DES access card, then provide my NT credentials to get access to my webmail which lead me through a link to a peoplesoft application with it's own access controlls so that I could sign up for SSO. Providing a single set of credentials and having all of the services recognize me would have made life much easier. Of course a good counterpoint is that anyone who was able to spoof my credentials would then have acess to all of those resources, but this was generally true of the cumbersome system, as long as you had access to the email password you could retrieve/reset most of the others.

  • oh cool (Score:1, Flamebait)

    by zephc ( 225327 )
    just when I thought security-related articles couldn't get any more boring, Sun releases XACML.

    [/tongue-firmly-in-cheek]

  • I dont get this (Score:2, Insightful)

    by Timesprout ( 579035 )
    What exactly is the need for this 'new' language. I get the impression that really this system just defines some interfaces and uses XML to allow various aspects of the implementation to communicate. Not exactly rocket science and certainly not worthy of a new language IMHO. What exactly does it do that XML and some well defined schemas cant?

    Its some what strange that given the recent 'commitment' from SUN to clean up the J2EE API's they want to foist this on us as I assume the enterprise is where it will see most usage.Is this sone sort of bastard child from the slightly less than successful Liberty project?
  • Q: What Open Source license are you using? We are using a modified BSD license. This is a true Open Source license with no "viral" effects.

    Almost sounds like they are either a)trolling for liscensing wars or b)trying to allay managerial fears about loss of code controll. While I would agree with them that for their purposes (and the purposes of any project/standard which needs to be integrated into the core of both commercial and non-commercial code) that the BSD liscense makes more sense I don't think they have to implicitly slam other liscenses like the GPL through use of MS like terms.

  • XML stone soup (Score:5, Interesting)

    by alext ( 29323 ) on Tuesday February 18, 2003 @07:38PM (#5330520)
    Like so many other "XML-based" standards, XACML is horribly constrained by the lack of general logical or procedural primitives in XML. As we all know, XML is not a programming language - it was never intended to be computationally complete - yet there seem to be a neverending stream of attempts that effectively try to turn it into one.

    It is a fundamental mistake to try to shoehorn semantics which will generally include logic - such as an access control decision - into a language which has no support for them. While XACML "is not intended to form the basis of an authorization decision by itself" it must of necessity include the means to combine and modify rules - hence requiring logical operators which of course have no standard representation in XML.

    The specific result is that each attempt to use XML for anything other than the simplest semantics (SOAP, Schema, XSLT, JSP...) must invent its own representations of operators, variables, modules and so forth.

    The general result is one unholy mess. We, the poor bloody coding infantry, have to face learning a dozen or more ways of representing the same fundamental concept in a multitude of languages, each supposedly specialized for a narrowly-defined task, but in reality incorporating almost-but-not-quite-all the features of a general purpose language. XML's ugly syntax becomes the least of our problems - that can always be hidden by visual tools or 'generators', but no tool is likely to be able to reunite fundamental concepts fragmented into so many different representations.

    Standards such as these do not represent progress, they represent a growing mass of redundancy that one day will have to be refactored into more coherent form. Anyone who studied LISP, or some other language capable of representing the popular data and programming paradigms (logic, procedural, declarative...) will be aware that common ways of representing such semantics have been known for decades. The fact that the practice of XML continues to ignore such basic prior art is an extraordinary indictment of the state of our industry today.

    I welcome any explanation from the individuals or organizations concerned as to what obliged them to make yet another idiosyncratic elaboration of the generally incoherent and unusable body of XML specifications.
    • I'm sure you're one of those people who insists on doing their configuration through a language specific construct, such as using eval() in Perl.

      XACML, as well as a few other XML "languages" is useful in that the policy is portable and everyone can benefit from better tools to work with the language. XML provides a middle ground for these languages. Sure, it doesn't have operators or behave like a programming language...but every programming or scripting language has several means of reading XML.
      • I'm sure you're one of those people who insists on doing their configuration through a language specific construct, such as using eval() in Perl.

        Not sure I follow you - what kind of construct would not be language-specific?

        XML provides a middle ground for these languages.

        "middle ground", "vocabulary" and "ontology" are certainly the kind of phrases you see in conjunction with XML. Unfortunately they mean very little.

        every programming or scripting language has several means of reading XML.

        No doubt. And probably a means of reading CSV files too. If you are implying by this that the ability to read XML structures is a significant contribution to the generation or interpretation of such languages as XACML then I think we'd have to disagree.

        XML here is a simple "wrapper" or syntax abstraction for the concrete syntax underlying XACML (or whatever). By itself, does nothing to constrain or interpret the latter.

        To take a simple example (from a guy called Philip Wadler, who has this on a T shirt)

        1. Start with a mathematical function, say 2x

        2. Now represent it in a convenient programming language, say Scheme: (lambda (x) (* 2 x))

        3. But in XML, the syntax has to be explicitly flagged in frequently gruesome detail:

        <abstraction>
        <var>x</var>
        <expression>
        <appl ication>
        <const>*</const><arguments>
        <const>2</c onst>
        <var>x</var>
        </arguments>
        </application>
        </expression>
        </abstraction>
        For any non-trivial language, XML is just baggage, it doesn't add anything useful.
        • Not sure I follow you - what kind of construct would not be language-specific?

          I meant not specific to the programming language(s) with which the construct is being consumed.

          "middle ground", "vocabulary" and "ontology" are certainly the kind of phrases you see in conjunction with XML. Unfortunately they mean very little.

          They actually mean quite a bit to some of us. If you've ever found yourself in the middle of a situation in which integration between a few complex systems is involved, all from different vendors, you would find reasons to overlook XML's warts. XML (or should I say: the software that has sprung up to support it) does offer you a more accessable programming model, which leads to more productivity, quicker project cycles, etc. When performance and verbosity are big issues, such as is the case when using smart cards and limited resource devices, XML can be transformed easily to other formats, such as ASN.1. Look at OASIS XCBF.

          Yes, XCBF could have just done it all in CSV, but instead they chose something that has good schema definition languages, good processing tools, excellent coverage by the technical press, and dare I say -- unprecedented market acceptance.

          2. Now represent it in a convenient programming language, say Scheme: (lambda (x) (* 2 x))

          I think thats a slightly different use case than XACML is addressing. XACML is about asserting policies. No one is trying to do mathematical calculations in it. I generally agree with you here, I've opted away from XML in cases where I had to describe methods moreso than properties. There is one exception, however. ANT. I find it more convienient that the .sh files or make files I used to use.
          • I meant not specific to the programming language(s) with which the construct is being consumed.

            Well, you are simply shifting the problem from the programming language to the other, "language-independent" language. In reality, there's no reason to privilege one language over another arbitrarily, and certainly not to mandate the use of multiple, highly redundant languages.

            "middle ground", "vocabulary" and "ontology" [...] actually mean quite a bit to some of us. If you've ever found yourself in the middle of a situation in which integration between a few complex systems is involved, all from different vendors, you would find reasons to overlook XML's warts.

            Passing over the obvious question regarding the decisions never to address XML's admitted warts but always to effectively compound them, you refer again to the XML programming model and its supposed advantages.

            Once again, I have to point out that the relevant language, the one actually expressing the information we are interested in, is not defined by (constrained by) the XML specification but by higher-level specifications such as XACML. Any appeal to productivity, efficiency etc. must therefore show how XML tools help manage XACML semantics specifically, in comparison to standard language processing tools such as YACC.

            Any transformation from XACML using standard XML tools cannot, by definition, improve on a representation of the underlying concrete syntax of XACML, since they know nothing about it.

            Similarly, any appeal to authority regarding the acceptance of XML is no more relevant than the acceptance of ASCII. Naturally this doesn't stop every new language ("vocabulary") being described as "standard XML", but such descriptions are wholly misleading.

            (lambda (x) (* 2 x))

            I think thats a slightly different use case than XACML is addressing. XACML is about asserting policies. No one is trying to do mathematical calculations in it.

            You appear not to have read the specification. Section A 14 describes the logical, arithmetic and other functions of XACML in some detail. It looks as though someone has invested considerable effort in deciding how 2x should be expressed in this "Access Control Markup Language".
            • *sigh*

              Why don't you write a paper on how much better specialized grammars and scripting is than XML, then present it to the industry?

              Make sure you format the paper in tex or groff or something else that doesn't use spurious ''.

              I've been down the yacc route, and JavaCC, in the past and I am happy to use XML from now on wherever I can. You are free to stay with the old school way if you like. The critical mass is with XML, and it will get better.
        • OK, I'm just a Java hack who's used XML in a bunch of places, but, errrm... XML is not a programming language. It's a file format. You don't do maths in XML, it doesn't replace C or Lisp or asm, it replaces .xls and .csv, hell even .jpg if you want.

          I may be being exceptionally thick, but I just don't get your example, you seem to be saying that just because turning Scheme code into (an arbitary) XML layout makes it take more space, XML is useless. I'd argue that's completely irrelevent. XML is for representing data.

          I should use a counter example I guess. How about you have a trading system which passes details of trades to some backend accounts system. It uses good old csv, so you get a file like this:

          RHT, 300, 4.51, JBLOGG, JDOE, 19-2-03
          IBM, 10000, 1.06, JDOE, JBLOGG, 19-2-03

          Transform that to XML:
          <txn>
          <stock>RHT</stock>
          <quan>300</quan>
          <pric e>4.51</quan>
          <buyer>JDOE</buyer>
          <seller>JBLOGG </seller>
          <date>19-2-03</date>
          </txn>
          <txn>
          <s tock>IBM</stock>
          <quan>10000</quan>
          <price>1.06< /quan>
          <buyer>JBLOGG</buyer>
          <seller>JDOE</selle r>
          <date>19-2-03</date>
          </txn>
          (apologies for random spaces and semicolons slashcode seems to want to add)

          Now, I'm not saying the latter is smaller. If data size matters, don't use XML. It doesn't matter to me (usually). But it's more human readable (which is sometimes nice). It's more flexible (when the sending system adds an extra field it just does so, the recieving system just ignores it - try that with csv!). It's more easily describable (want to tell people what format you use? just mail them the schema and voila - they can read your data). I don't believe XML is a massive leap forward, but it simplifies a lot of things and removes a lot of potential confusion. Standards are a good thing.

          I can't see any reason (other than size, and you can always zip your files) not to use XML in the vast majority of applications which transfer/store textual (non-binary) data. You get free tools, you get free parsing/writing libraries.

          • Sure, I don't have a big problem with XML being used to express data. The problem with XACML and its ilk is that people are trying to use XML to express logic, maths, control etc. just like a real programming language. Worse, the way they do this is usually partial and specific to every Tom, Dick and Harry XML "vocabulary".

            • I agree that would be bad, I'm not convinced that's what's happening here. I've only skim read the spec, but it basically looks to me like just a collection of schemas. One describes what a request looks like, one describes what a response looks like, and one describes the format of what is basically a config file. The code which Sun have released takes a request, looks at the config, and creates a response. But is written in Java, not XML (?). If you decided not to use XML, but instead CSV for all your requests, responses and config, the Java code would stay the same, it would just need different file parsers.

              I really fail to see what the problem is here. The last thing you want is to express authentication configuration in programmatic code! I mean, you can't write a .htaccess file in C can you?
              • it basically looks to me like just a collection of schemas

                It isn't. Take a look at the appendix, you'll find 30-40 pages on data types, expressions, operators etc. - deja vu all over again.
        • While I wouldn't call myself a big fan of XML, you're simply wrong in your example. XML is a data representation language. In most languages, data and expressions are more or less the same. For instance, take your example

          f(x) = 2x

          Now, you converted to Scheme/LISP and then to XML. That's bad. A more fluid translation to XML could be:

          <function name="f">
          <arguments>
          <symbol name="x"/>
          </arguments>
          <body>
          <operator name="*">
          <constant value="2"/>
          <symbol name="x"/>
          </operator
          </body>
          </function>

          Compared to C:

          int f(int x)
          {
          return 2 * x;
          }

          Scheme/LISP:

          (defun f (x) (* 2 x))

          C++:

          struct
          {
          typedef int results;
          typedef int argument_type;

          int operator()(int x)
          {
          return 2 * x;
          }
          } f;

          The XML isn't really that bad.
          • You appear to be under the same impression as AC above, that this is a debate about conciseness. It's actually about coherence.

            The fact that XACML invents most of a full programming language, as does XSLT, JSP ad nauseam results in massive duplication and hence confusion, lost productivity, efficiency and flexibility.

            You are welcome to express your logic in XML syntax, just don't invent a different syntax, grammar and feature set for each "application".
        • Everyone is using XML to do away with specialized grammars for every problem domain. The human element is always the weakest and the slowest. If you can simplify things for the impementor by using a spec that is well known and in which it is relatively easy to reason, then you have eliminated a great problem. I would love it everyone would exercise a little brain muscle and just learn lambda calculus, but that probably won't happen any time soon. So we'll just have to make due with the lowest-common denominator which is XML (which is self-documenting if written properly - so that's ONE nice feature).
          • This is nonsense both in theory and in practice - XACML has a grammar, and it isn't XML. The spec's 220 pages describe this grammar - the mere fact that they say things like

            The MatchId attribute SHALL specify a function that compares two arguments, returning a result type of boolean.

            instead of providing a formal definition such as a BNF can't disguise this.

            Now if this spec was part of a coherent and properly factored set of XML standards the job of the implementor would be vastly easier, since implementations of things like expression evaluators would be common and could be shared - easier to learn, write and maintain.

            Rather than pretending to people that it's "relatively easy" to implement specs. like XACML using standard XML tools, a more useful contribution would be showing how useable Scheme, Haskell or other language semantics can be mapped to XML (if required), so helping rationalize the situation.

    • Here's a great example of a use for XML-based language. I don't say it's better, I don't say it's anything new, it just helps in many ways making everything more standard.

      Company A wants to exchange data(ie order forms) with Company B. (Amazon and CDNow for a lack of better example).

      Now, if they used a proprietary format, it's all good, they make the specs together, then each implents it.

      Then, Company C wants to be included in the exchange too. They send the specs of the file format and Company C implements it.

      And so on. It could introduce many bugs since they don't have the same implementation details, if A and B want to add a field, but not C, C will still have to change it's implementation, unless the format allows additional field without breaking compatibilities with previous version of the file format.

      However, if they used a standard format, whether or not it's XML-based, they would only have to take a reference implementation to parse the data, and thus will probably have much less differences, bugs and security issues.

      XML is just a nice way to make a standard, it always parses the same way, and don't care when you add new fields, you must really change the whole language to break compatibilies with previous versions.

      XML is just that, a nice standard way of doing standard language for information exchange. You could do it in CVS for example, but it's hardly flexible like XML. You can create proprietary formats, but it will take more time, and each companies are likely to have to build the implementations themselves. With XML-based language, it's very easy to do a reference implementation since XML always parses the same way and is very flexible.

      Hope that helps.
    • XML is not a programming language - it was never intended to be computationally complete

      Now repeat after me: XML is basically just a syntax. It was never intended to be computationally complete in the same way as marking up things with balanced parentheses is not computationally complete. Yet you can map your favorite programming language into an XML representation, and vice versa.

      Anyone who studied LISP, or some other language capable of representing the popular data and programming paradigms (logic, procedural, declarative...) will be aware that common ways of representing such semantics have been known for decades. The fact that the practice of XML continues to ignore such basic prior art is an extraordinary indictment of the state of our industry today.

      The fact that someone tries to come up with a standard that would be widely accepted shows our industry as a maturing one. Sorry, but Lisp doesn't cut it for the IT masses in general. It missed its chance back then. It's a generic language, with strong background in programming, and it doesn't have such an emphasis on validation of semantically-loaded subsets as XML applications had from the very beginning.
      • It was never intended to be computationally complete [...] The fact that someone tries to come up with a standard that would be widely accepted shows our industry as a maturing one

        I agree with your first statement, which is not surprising as I stated it in my first message, but I don't think many will agree that any set of standards, no matter how redundant, inflexible and unmaintainable, represent progress in the industry.

        Your views on LISP per se are not particularly relevant, the point is that there are generic programming concepts in multiple XML specs. that can and should have been factored out. XML is not, as you say yourself, an alternative to LISP, but XML with appropriate coherent extensions could well be.
    • Before writing all this, it would be helful to actually read the XACML spec. (I did - I am actually listed as one contributor to it). It is nothing more then a thin XML layer on top. You can mark up LISP if you want - it means nothing exept you can use a lot of handy parsers to read it in.

  • Okay, an attempt to explain... (Score:4, Interesting)

    by Abcd1234 ( 188840 ) on Tuesday February 18, 2003 @07:43PM (#5330548) Homepage
    This is really a bit of a niche domain (in that, system administrators and other folks are interested, most other people aren't).

    Basically, in the world, there are many scenarios where it would be VERY useful to be able to enable access controls on various resources in a system. By "access controls", I mean rules which define who can perform actions on given resources. This sounds so general because it is very general. The purpose of XACML is to provide a language which allows you to specify these rules, or policies, in a nice format independant of the rest of the system (data storage, etc) for any number of domains, and provides software to implement the required components for such a system.

    As a solid example, you could use XACML, a central PDP, and a PEP on a set of firewalls to control which IPs have access to what. You'd have to write a PEP for the firewalls, and set up a PDP to handle the requests, but once this is done, you could use XACML to write firewall rules!

    Another example, suppose you have a user trying to access their email. You could have a PEP in the client which talks to a PDP to determine if the user is allowed to perform various actions on the mailbox (read, write, etc). In this case, you'd use XACML to determine who can perform what actions on the mailbox.

    In both of these cases, XACML defines the language PEPs use to talk to PDPs, and also specifies a common XML language for defining the policies to determine who can do what.

    In essence, XACML abstracts these concepts of policy enforcement, rule definitions, etc, and wraps them up in a nice XML language which can be used in any component which implements the XACML specificiations for a PDP and PEP. Why would you want to do this? Well, first, it allows you to use plug in in an access control system, rather than having to roll your own. This is good. Second, anyone who implements the XACML standard can interwork. So, I can write a PEP for my email client, and use Joe's PDP to enforce policy in my system. Third, because all your systems now use a single language, you can centralize the policy database and use common tools to manage all of them. An administrators dream!

    Now, this is really important people, this has NOTHING TO DO WITH DRM! Or Palladium! Or any other conspiracy theory you want to come up with. This is simply a tool for software developers and system administrators to easily integrate a standard access control framework into their systems.

    * Note, in the previous, PDP - Policy Decision Point, and PEP - Policy Enforcement Point.
    • This sounds so general because it is very general

      So why not use a general-purpose language rather than inventing your own?

      • Because there's no such thing.

        I work in a place that's responsible for software with complex business rules surrounding access control (authentication and authorization), written in ASP, Java, Perl, C#, and VB. So then what would YOUR solution be for me? To write separate access control mechanisms for each one in their own languages? Or scrap all of the existing code and pick one language? Or have then all connect externally to a "general-purpose language" and end up dumping all of the dissimilar access control rules into one container and struggle with how to consistently store and implement them?

        Sun's done much of that with their new "language" (although I disagree with that description). XML is perfect for storing this kind of information because you have to be able to not only self-describe the access control rules, but also have the flexability to define them in complex and embedded ways.

        Looks like an interesting technology to me, and certainly a compliment (if not extension) to JAAS, which is a arguably the most popular public application development security schema around. Unfortunately, it describes its access control rules in Java, not the language-independant XML format in Sun's new technology.

Slashdot Top Deals

THEGODDESSOFTHENETHASTWISTINGFINGERSANDHERVOICEISLIKEAJAVELININTHENIGHTDUDE

Close