Showing posts with label xml. Show all posts
Showing posts with label xml. Show all posts

Tuesday, December 23, 2014

Yosemite Project and other Chimera

In Greek mythology, the chimera  was a monstrous fire-breathing hybrid nightmare composed of the parts of more than one animal, a lion with the head of a goat rising out of its back, and a tail with a snake's head; a nasty piece of business, eventually dispatched by Bellerophon with some assistance from Pegasus.


Chimera was also the subject of a presentation by Jeni Tennison, OBE, of the Open Data Institute and W3C TAG, at XMLPrague 2012, entitled "Collisions, Chimera and Consonance in Web Content." In this presentation, she introduces a compelling argument that suggests that currently, in the web, we are dealing with four different formats: HTML, XML, JSON, and RDF.

In many ways, these formats complement one another. Sometimes, they clash, creating impedance and dissonance, and sometimes they merge, forming weird and wonderful hybrids. Tennison's presentation is really quite remarkable, and well worth watching as each of these formats evolves.

As I have previously mentioned, another set of presentations, from Dataversity and SemanticWeb.com, are also worth watching and paying attention to. These deal with the Yosemite Project, ongoing work which intends to position RDF as a Universal Healthcare Exchange Language. This work is important in part because it directly addresses how to go about migrating and transforming between formats, once you can establish a common representation using RDF. In many ways, this is a mythical undertaking, but also very promising.

For instance, with the work underway with Project Argonaut and HL7 FHIR, you are looking at a standard for healthcare that comes in two flavours, XML and JSON; however, like its predecessor HL7 CDA, FHIR relies on a human-readable portion, which in this case means HTML5. Add to that the work underway with Yosemite - go watch the presentations! Now you have an ecosystem that supports appropriate use of HTML, XML, JSON, and RDF - the subject of  Dr. Tennison's XMLPrague presentation - now in the context of healthcare. This is really what John Halamka has referred to as the "HTTP and HTML for healthcare".

If you broaden your horizons just a little, you will see some of the work which is also being carried out by Health & Human Services and the NIEM Health Domain, as a counterpart to the work of HL7 International. NIEM is primarily an XML-based standard, but in the last couple years, the underlying tooling there is expanding into UML-, JSON-, and HTML-based representations. With the support of some underlying ontology work, perhaps in concert with Yosemite, NIEM too could be used to create linked health data. These are all very exciting, very important things that are happening very very quickly, and it is a great time to get involved with some of these projects and initiatives.

Wednesday, January 01, 2014

Liquid XML 2014 Beta

For the last couple months I have been using a beta version of Liquid XML, for a number of reasons. I have a laptop, and I find Liquid a little easier to use on a smaller screen than XML Spy or Oxygen, and I have found the support for XML Schemas 1.1 very useful. This is new to 2014, but has been available in XML Spy and Oxygen for a while.

Hopefully XSD 1.1 becomes mainstream. It's just such a complete improvement over XSD 1.0.

With Liquid XML, I can also flatten composite schemas. I have been doing this using CAM Processor, and it's not something I need to do very often; and more often than not, I just roll my own transform for this. Still, it's useful. In the coming year, we are going to see a continuing shift from XML to JSON technologies on both the client and server, but I think this is misleading. At the same time, server-side XML is reaching a renaissance, because server-side validation and transformation are a critical part of client-side delivery of conformant JSON. It's as simple as that.

XPath is the power behind XQuery, XSLT, OASIS CAM and ISO Schematron. Now, it's an important part of XML Schemas; and XPath is developing very quickly, considering most people who are using XPath are still using version 1.0, and yet there are very mature features coming in version 3.0 - so it's still a good time to be working with XML; and it's a great time to be working with JSON as well.

Tuesday, December 31, 2013

Using XSD 1.1 with HL7 as a Schematron replacement

Several years ago, I posted an article on IBM developerWorks about using OASIS CAM and David Webber's CAM Processor tooling to extend HL7 v3 schemas to better handle the extra conformance levels required by the HL7 RIM, particularly dealing with null flavors. At that time, CAM Processor was relatively new, and CAM is now reaching a very good level of maturity in the NIEM community; however, I suspect that HL7 specifications will always be more demanding than NIEM, in part due to the complexities of the RIM. The best alternative has always proven to be XSD 1.0 + ISO Schematron. At the time, I had considered using XSD 1.1, which provides assertions, but at the time, XSD 1.1 was still in development, and the CAM tooling just worked.

Recently however, it dawned on me that XSD 1.1 is now a W3C Recommend, and it has evolved, much like CAM, to include features that originated in Schematron. Actually these ideas didn't originate in Schematron, but that's another story.

As opposed to OASIS CAM, which really combines the core strengths from Examplotron and Schematron - using a reduced instance XML instead of a hierarchical grammar, and using XPath to define assertions - XSD 1.1 retains the hierarchical grammar, adding Schematron-like assertions to the extension/restriction process which is already built into XSD. So, to test data-type assertions on an element, you restrict the type definition for the element; to test conformance assertions on an element, you extend the type of the element to include any necessary assertions.

For example, in the HL7 RIM, an element can be Optional, Required or Mandatory - with an extra level, Populated, in some realms. For Optional, Required or Populated elements, a nullFlavor attribute is permitted in place of absent valued information, to describe why the information was absent. The phrase null flavor is confusing, but really it's just a reason why the information is absent. For Mandatory elements the nullFlavor attribute is forbidden.

In an existing XSD schema, you can determine which elements are Mandatory because they have minOccurs which is greater than 0, and isMandatory is true [ed. this has been edited]:
<xs:element name="processingCode" type="CS.CA"
   minOccurs="1" maxOccurs="1">
   <xs:annotation>
      <xs:appinfo>
         <mif:attribute name="processingCode"
             minimumMultiplicity="1" maximumMultiplicity="1"
             isMandatory="true" isImmutable="false">
            <mif:businessName name="D:Processing Code"/>
            <mif:annotations>
                <mif:appInfo>
                    <mif:mapping sourceName="Sample">
                        <mif:text>
                            <mif:p>[MSH-11.1]</mif:p>
                        </mif:text>
                    </mif:mapping>
                </mif:appInfo>
            </mif:annotations>
            <mif:type name="CS.CA"/>
            <mif:vocabulary>
                <mif:conceptDomain name="ProcessingID"/>
            </mif:vocabulary>
         </mif:attribute>
      </xs:appinfo>
   </xs:annotation>
</xs:element>
In order to add an assertion using the new features in XSD 1.1, we need to remove the type attribute from the element, and extend it as a complex type:
<xs:element name="processingCode" type="CS.CA"
   minOccurs="1" maxOccurs="1">
   <xs:annotation>
      <xs:appinfo>
         <mif:attribute name="processingCode"
             minimumMultiplicity="1" maximumMultiplicity="1"
             isMandatory="true" isImmutable="false">
            <mif:businessName name="D:Processing Code"/>
                    . . .
            <mif:type name="CS.CA"/>
            <mif:vocabulary>
                <mif:conceptDomain name="ProcessingID"/>
            </mif:vocabulary>
         </mif:attribute>
      </xs:appinfo>
   </xs:annotation>
   <xs:complexType>
      <xs:complexContent>
         <xs:extension base="CS.CA">
            <xs:assert test="not(@nullFlavor)"/>
         </xs:extension>
      </xs:complexContent>
   </xs:complexType>
</xs:element>
If additional assertions are required, they can be added to the same extension; however, in this case, the only assertion we require is to ensure that the Mandatory element does not have a null flavor when we validate an instance message. All that remains now is to change our XML editor so that it is using Xerces 2.11.0 or higher, which supports XSD 1.1, and when we validate a message, we will be alerted if there is a processingCode element which is null flavored.

Monday, July 29, 2013

JSON vs. XML: Holy Wars and Container Elements

I've been working on a demo based on David Webber's CAM/Open-XDX demo for Prescription Medication Checking (PMIX). Open-XDX offers an easy way to set up a schema-based REST API for XML and JSON. I am building a mobile app with PhoneGap, AngularJS and Saxon-CE.

Originally, my demo mobile application used Saxon-CE with a bit of JQuery to coordinate Ajax calls. I soon replaced JQuery with AngularJS because I wanted a chance to use this framework, and because I liked the name "AngularSaxon". Meanwhile, I was also figuring out a way to embed a Firefox OS build within an Android PhoneGap build.

It soon became apparent that Angular, at 80K, could perform many tasks faster than Saxon-CE, at 800K, and since I had both JSON and XML available, I started shifting my focus, to allow a time trial between the two wire formats. One thing I discovered is that, whereas XSLT can handle something like:

   <Prescription id="1">...</Prescription> 
   <Prescription id="2">...</Prescription> 

...in the specific case where there is only one element, in JSON, this surfaces as the difference between an Array and an Object, which results in problems using Angular's ng-repeat directive. I was able to create a workaround in my JavaScript objects, as detailed below.

I had already created an Angular Service to handle rendering in both XSLT, using Saxon-CE, and in JSON. This Rendering Service already contained an exposed copy of the data returned from an API call, triggering an Angular Controller when the data is ready. I added the following method to the Rendering Service to insert an absent Array for a container element:

   renderingService.fixJSONContainer = 
      function(parentNode, childName) {
         if (parentNode !== undefined) {
            var childNode = parentNode[childName]
            if (!Array.isArray(childNode)) {
                parentNode[childName] = new Array(childNode)       
            }
            return parentNode[childName]
        }
        return []
    }


This helper method is available to the Response Controller, since it has already been Dependency Injected. In the Response Controller, I made the following changes to the render method for JSON:

   $scope.$on('renderJSON', function() {
    $scope.fixJSONContainers(renderingService.data)            

    $scope.pmix.resp.prescReport = renderingService.data[...]
    $scope.pmix.response.prescriptions =
       $scope.pmix.resp.prescReport['pmp:Prescription']
  });
         

  $scope.fixJSONContainers = function(data) {
     var prescriptionArray = 

        renderingService.fixJSONContainer(data[...], 
        'pmp:Prescription')
     for (prescriptionNode in prescriptionArray) {
        prescriptionDrugArray = renderingService.fixJSONContainer(

           prescriptionArray[prescriptionNode], 
           'pmp:PrescriptionDrug')
     }
  }


The local method fixJSONContainers is specific to my schema, and requires intimate knowledge of the schema; where for instance, the CAM elements have makeRepeatable. Other than that, this solution is generic. In my HTML View, Angular handles the data-binding using ng-repeat directives:
 
   <ol id="prescriptions">
      <li ng-repeat="prescription in pmix.response.prescriptions">
      <h3> Prescription #:
         {{prescription['pmp:PrescriptionNumberText']}}
         ({{prescription['pmp:DrugRefillNumberCount']}})</h3>
      <div ng-repeat="prescriptionDrug in 
          prescription['pmp:PrescriptionDrug']">
          <div> Prescription: 
              {{prescriptionDrug['pmp:DrugProductNameText']}}
              - {{prescriptionDrug['pmp:DrugStrengthText']}}
              - {{prescriptionDrug['pmp:DrugUnitOfMeasureText']}}
          </div>
       </div>
    </li>
 </ol> 
 
Once the changes have been made to the underlying Services and Controllers, the HTML View is very tight and concise, which is part of the magic of Angular. Autowired data-binding takes care of the rest.

Tuesday, May 07, 2013

TermInfo Discussion at HL7 WGM Atlanta 2013 (SIM&A)



Okay, HL7's RIMBAA Working Group hasn't changed their name to SIM&A yet ("Simba"), but it looks like that is the name that is going to stick to reflect the group's broadened scope.

One issue that this and other working groups are determined to put to bed is that of negation, particularly with TermInfo vocabulary sets like SNOMED CT. The problem is that not all vocabulary sets support negation implicitly, by providing vocabulary terms that are already negated. SNOMED CT does. The big question then is, should you always use the implied negation in the vocabulary set if it is available; or should you sometimes, or never use it.

The alternative, for HL7 v3 at least, is to use a negation indicator, messaged as a negationInd attribute on the element in question... so this is effectively metadata, and the problem with metadata is that there is no guarantee that the receiver interprets it correctly, if at all. For many use cases, this probably doesn't matter much, but for clinical diagnosis and decision making, for allergies, for drug interactions, and even in the context of non-health applications like Corrections and Defense, Person-of-Interest queries need to properly take into account null flavours and negations; so there is a strong Public Health and Public Safety aspect to this discussion as well.

So it is an important concept, and people need to reach agreement on the correct way to do this; however, this issue goes back a number of years, so I'm curious to see where it goes. My own thoughts are that a better way to do this from the start would have been to use a tri-state negation indicator, which indicates "positive", "requires negation", or "implictly negated"... but it's too late for that now, and it always has been.

Here are the details from the RIMBAA forum (via Rob Hausum, MD, Hausum Consulting):
The TermInfo negation discussion at the Atlanta WGM will be held in Q1 Tuesday (tomorrow).  Following a brief introduction, we intend to devote the remainder of the quarter to this topic.  We would like to come away from the quarter with a concrete plan to create and provide guidance on this important topic.  That may involve a focused TermInfo ballot on negation, but the specific form and scope is still open for discussion.

For those who aren't in Atlanta, we expect to have remote participation capability via GoToMeeting (details below).  Please join the discussion, or, if you are unable to attend either in person or remotely, feel free to pass along any comments/questions/concerns.

Rob

GTM details:

1.  Please join my meeting.

2.  Use your microphone and speakers (VoIP) - a headset is recommended.
Or, call in using your telephone.

Denmark: +45 (0) 69 91 89 33
Australia: +61 2 8355 1031
Austria: +43 (0) 7 2088 1033
Belgium: +32 (0) 28 08 4342
Canada: +1 (647) 497-9371
Finland: +358 (0) 942 41 5770
France: +33 (0) 182 880 159
Germany: +49 (0) 811 8899 6925
Ireland: +353 (0) 19 030 050
Italy: +39 0 693 38 75 50
Netherlands: +31 (0) 208 080 208
New Zealand: +64 (0) 9 925 0481
Norway: +47 21 54 82 21
Spain: +34 911 82 9890
Sweden: +46 (0) 852 500 179
Switzerland: +41 (0) 435 0167 65
United Kingdom: +44 (0) 207 151 1806
United States: +1 (213) 493-0619

Access Code: 912-947-024
Audio PIN: Shown after joining the meeting

Meeting ID: 912-947-024

GoToMeeting®
Online Meetings Made Easy®

Monday, February 06, 2012

Hot processing!



Great story from Ken Holman, quoted for coolness and also for #refrigerator...


Hot processing!
So I'm standing here at my desk preparing my UBL 2.1 PRD3 D1 package and I have two very long XSLT transformations to run. One takes 98 minutes and the other takes 124 minutes, running in Java in BSD on my Unibody MacBook 2.66GHz I7 (dual core; quad process). Input file 10Mb; output files total 183Mb.
I used to run these two tasks sequentially, but I today checked out "Activity Monitor" and discovered that while each transformation starts off using about 250% CPU time (sharing processors while building the memory structures), they quickly become single processor 100% (±2%) only (while traversing the memory structures).
So I decided to run them simultaneously instead of sequentially, saving me (theoretically) close to 98 minutes since most of the time appears to be at 100% and when they are both running Activity Monitor says they are both running at 100%.
So far so good ... but within minutes the fans on my machine get too noisy to talk over! I check the status bar and, sure enough, both fans are running >6000rpm. My fans so very rarely make any noise, so this is very noticeable and annoying.
My very wise wife suggests I go to the kitchen and get the flat-bottomed aluminum frying pan to place under my machine, upside down so the flat part of the pan is full on the bottom of the Mac. Maybe two minutes later the fans are running <4000rpm and we can talk without raising my voice over the fan.
Well, now as I'm typing this Google+ post the frying pan is getting hot! The fans are up to 4800rpm again and slowly rising.
So, I've just gone to the kitchen, brought out a second aluminum frying pan, put that one under the Mac, and put the first frying pan into the refrigerator to cool down for the next swap. Within a minute the fan is back down <4000rpm.
My review and editing of the above takes five or 10 minutes. Already this pan is heating up as it isn't as substantial as the first pan ... fan speed up to 4400rpm ... but the first pan will be cold by the time I need to swap again.
Such a simple improvement! Wish I'd thought of it.
View or comment on Piers Hollott's post »

Monday, January 09, 2012

XML Prague 2012 conference sessions


XML Prague 2012 conference sessions:

  • Opening Keynote - Jeni Tennison 
  • The eX Markup Language? - Eric Van der Vlist
  • XML and HTML Cross-Pollination: A Bridge Too Far? Robin Berjon and Norman Walsh
  • What XML can learn from HTML; also known as XML5 - Anne Van Kesteren
  • Panel discussion on HTML/XML convergence - Norman Walsh
  • XProc: Beyond application/xml - Vojtch Toman
  • Understanding NVDL - the Anatomy of an Open SourceXProc/XSLT implementation of NVDL - George Bina
  • JSONiq: XQuery for JSON, JSON for XQuery - Jonathan Robie, Matthias Brantner, Daniela Florescu, Ghislain Fourny and Til Westmann
  • Corona: Managing and querying XML and JSON via REST Jason Hunter
  • Treating JSON as a subset of XML: Using XForms toread and submit JSON - Steven Pemberton
  • RESTful XQuery - Standardised XQuery 3.0 Annotations for REST - Adam Retter
  • Compiling XQuery code into Javascript instructionsusing XSLT - Alain Couthures
  • Implementing an XQuery/XSLT hybrid - Evan Lenz
  • Transform.XQ: A Transformation Library for XQuery 3.0 - John Snelson
  • Building Bridges from Java to XQuery- CharlesFoster
  • My first XSLT editor - Tony Graham
  • A Wiki-based System for Schema and Data Evolution - Lorenzo Bossi and Alberto Trombetta
  • Standards update XPath/XSLT/XQuery 3.0 - Michael Kay and Jonathan Robie
  • Closing keynote - Michael Sperberg-McQueen

Friday, October 07, 2011

Ada Lovelace Day 2011

Ada Lovelace day: in my little XML corner of the world, I have learned more than I could possibly mention from +Eve Maler , +Jeni Tennison , Priscilla Walmsley and +Lauren Wood.

Many thanks to all! 

Friday, September 09, 2011

Structured Product Labeling...

I am currently reading about SPL (Structured Product Labeling), an XML-based standard used in the pharmaceutical industry, engineered to reduce pharmaceutical error.
The SPL Standard, DailyMed, and the Consumer – DCLnews Blog
By DCL's Vincent B. Donadio, Editorial Contributions from DCL's Howard Shatz In 2005, the Food and Drug Administration (FDA) implemented an XML-based standard for drug labeling (among other thi...

Thursday, August 25, 2011

This is why I love MulberryTech's xsl-list...

This is why I love MulberryTech's xsl-list: sombody asks a question about an error message during parsing in oXygen using the Saxon 9 parser... and George Bina and Michael Kay respond with an answer, seemingly within moments.

xsl-list-digest-subscribe@lists.mulberrytech.com
Consultants specializing in XML Applications for Prose Documents | Mulberry Technologies, Inc.
XML and SGML implementation consulting for publishing from Mulberry Technologies, Inc.'s staff: Tonya Gaylord, Debbie Lapeyre, Wendell Piez, B. Tommie Usdin.

Wednesday, September 22, 2010

Ontology of Dream Landscape

A couple things I have been thinking about recently, which come together in this: even dreams typically have a location, but it is a unique quality of dreams, at least the ones I have been having lately, to feature a location in isolation, that is separated from character or context; and: in matters of taxonomy, more than three levels is seldom viable in practical terms, but two is seldom sufficient.

In the work I am currently involved in developing a financial application, I see a three-level vocabulary emerging which I have witnessed in other domains, typified as category, type and subtype.

If I was attempting to describe an ontology of dreams, therefore, I imagine I would use a category of "location", a type of location name or "realm", and a subtype describing each specific "locale" within the realm. So, for instance:

/location/a_forest/one_of_many_paths

What I would like to do is build an API, attached to a cloud storage, to allow people to describe their own dream landscapes in these terms. More on this as it develops. Please comment as you see fit.

Friday, May 14, 2010

Tab Sweep - 2010 05 14

Dare Obasanjo on Facebook:

Facebook’s Open Graph Protocol from a Web Developer’s Perspective

danah boyd on Facebook:

Facebook and "radical transparency" (a rant)

Not surprising that Facebook is facing criticism; I appreciate danah's demonization of transparency, and the distinction she draws between being exposed and exposing oneself. One of the things I appreciate about Twitter is that the level of exposure of any conversation I have there is dictated directly by the object graph of those involved in the conversation. If I want to curse and swear, I can engage someone in a conversation with whom this is appropriate. But there is always a risk of exposure.

Dare's point is also well taken on many levels, but particularly from my viewpoint, ontologically speaking, that Facebook is leveraging RDFa and not microformats, and that RDFa is an exponentially more robust technology specifically due to the use of namespaces. And what better way to identify arbitrary URIs as social objects than by using namespaces? In issues of transparency and privacy, it seems that disambiguation, ie clarification of social context will become increasingly important.

Reread danah's rant, especially the Zuckerburg quotes referring to the artificiality of sustaining a multiple identity. My own reaction to this is equally violent, and I call BS - all relationships in a social graph are virtualizations or supplementation of something that they are not, actual relationships. They are by definition artificial and demand disambiguation.

My travels in Flex-land keep coming back to the importance of namespaces outside the strict context of XML. Their time is coming; more widespread use of RDFa and the need for disambiguated rather than radical transparency are definitely indicative of this.

Wednesday, May 05, 2010

Seminal Granularity: I <3 the </>

It's no secret, I love me some XML, whether as an exchange format like XBRL, a messaging standard like HL7 or NIEM, or a document framework like DITA or DocBook. I am not sure what appeals to me so much about data-enrichment using tags, but it has something to do with reducing entropy by adding structure and meaning. In addition, I would rather model something using the sort of extension and restriction available in NIEM than the classical inheritance strategies presented by OOP. I have heard from several sources recently that the seachange from an object-oriented to declarative paradigm is underway, and I am pleased.

But more than this, I just love the angle brackets in a way I could never feel about dot-notation, and I am not alone in this.

I am attempting to develop a notion I am calling "Seminal Granularity." This notion appeals to my background in structuralist literary theory - "seminal" and "granular" are both agricultural references, both seeds, but whereas "seminal" has patriarchal overtones, granular is more mercurial. Between the two axes there lies a tension, bringing to mind a transclusive dilemma.

Simply stated, the transclusive dilemma is this: when faced with modifying an object, do you create a reference to the object for modification, a seminal approach which binds the new object to the original; or do you create a clone of the object, a granular approach which results in modification to the new object becoming estranged from the original, releasing the object through mimesis.

A viral licensed open-source project, for instance, is by design both seminal and granular. The project itself exists as a single seed, and it allows granular modification with the caveat that modifications are returned to the original seed.

Edit: there is also an odd kind of tie in with this short story, The Ice Box.

The transclusive dilemma is a real phenomenon; you cannot do both. Seminal granularity should be about finding ways to negotiate this problem. A wave can't be a particle either, right?

Tuesday, May 04, 2010

Talking Points: Collaboration and Documentation

A few years ago I wrote about a project I developed for my then employers, which I open sourced under the name CaseBook. The intent was to single-source end-user documentation which could be be transformed into internal and client acceptance test scripts. As I developed it, the project involved XML, Schematron, XSL and XQuery, hosted in an eXist database and accessed using webDAV.

At the time, I had barely heard of DITA, the Darwin Information Typing Architecture, but the approach I took shared some ideas with what I later came to learn about DITA, using concept maps, separation of topics into tasks and steps and so forth. In the mean time, DITA has gained a lot of traction, and my SourceForge page has been hit maybe 500 times.

I have been giving a lot of thought lately to collaborative writing. As Anne Gentle has pointed out on her JustWriteClick 'blog, DITA shines in environments which have a strong collaborative or Agile approach, since both of these emphasize timely repurposing and multipurposing. One of the problems I was addressing with CaseBook was collaboration between development, documentation and testing resources. Now, in part, this was because I was working in a small team, and had responsibilities in each of these areas.

I still think there is a lot of value in facilitating collaboration between these groups, and were I to develop this project today, I would start with the DITA Open Toolkit from day one.

In addition, for the last four months, I've been working with Flex, mxml and ActionScript. One thing that intrigues me about mxml is that it is XML. For instance, what if you could generate end user, acceptance or client walkthrough documentation automatically from the mxml source? Transforming mxml to DITA seems like a useful technique.

Any thoughts?

Saturday, November 21, 2009

More Semantic Silliness

<object>
<span property="dc:creator">Dan Brown</span>
<span property="dc:title">The Du Blinci Core</span>
</object>

...in which Tom Hanks plays a singleton node who discovers that he is somehow miraculously able to hold content, assisted in his search for meaning by Audrey Tautou, who along the way learns to re-purpose several hitherto erstwhile under-appreciated property attributes.
Sir Ian McKellen turns in a riveting performance as a priest who is actually an xml spy utilizing a Saxon transformer-implementation.

This perhaps is a film I would enjoy....

Friday, November 20, 2009

Sketches for a Group Membership Vocabulary

(Or the Strange Tale of RDFa and the Room with Two Doors)

I am sketching these ideas out here because I think they may be useful at some point, and I would really appreciate feedback; if this sort of vocabulary is already available somewhere, please ping me and let me know. And I'm going to save the RPG analogy for the end, because I know these can be deterrent. [ed. whatever! skip to the jump; it's funny!]

An activity I have had to address on several projects now involves profiling or gate-keeping groups of people or objects for the purpose of authorization or processing. For instance, in a CRM application, it might be necessary to tag potential customers as prospects, clients, inactive, etc. Or for a workflow application for a working group, it might be necessary to track people who are actively developing, people who have left the group, but are still useful resources and so on. I have yet to see a reasonable vocabulary for tracking these people. If such a vocabulary exists, I am sure it has many uses in a variety of contexts.

This vocabulary would have the following component(s):

Membership Status (mg:status):
This is the status of an individual, group or artifact within a larger community, given the following states, which should be mutually exclusive:
  • unknown - this is a nicety and not essential. Undefined.
  • prospect - potential only to be a group member.
  • candidate - selected by an automated process to become a group member, but not one yet.
  • nominee - recommended to become a group member by an existing member.
  • initiate - has completed self-registration etc, but not yet a group member.
  • member - an active member of the group.
  • banned - removed from group by process with proviso of reentry.
  • permban - removed from groupt by process with no proviso for reentry. TERMINAL.
  • alumnus - a non-active former member of the group. TERMINAL.
  • permanent - a member that can never be removed from the group. TERMINAL.
This list is likely not complete, but it represents a fairly typical group workflow model. When you enter the system, you are unknown, and are "promoted" to membership. At this point, you are ripe for the picking. At some point you may reach a terminal, but the majority of people will probably reside in the prospect and member categories.

So here is the RPG example:
A group of adventurers is exploring a location, when they reach two doors, one red and one blue. At this point, with respect to each of the doors, the two rooms could be described using the following RDFa-like pseudoterminology:

<room id="behind_the_red_door">
<member id="adv1" property="mg:status" content="prospect"/>
<member id="adv2" property="mg:status" content="prospect"/>
<member id="adv3" property="mg:status" content="prospect"/>
</room>


...and similarly for the room behind_the_blue_door.

Now, one of the adventurers discovers a key to one of the doors. At this point, this adventurer becomes content="candidate", whereas the other adventurers become content="intitiate" - they have an understanding of how to enter, but only the first adventurer has the key. However, since the door is now unlocked. Sicne the door is locked, only candidates can enter. When the first adventurer unlocks the door, the state of the room changes such that now candidates and initiates may enter (the state of the door in this case might be handled by a separate vocabulary - also this example hinges painfully poorly on the assumption that once unlocked, a door cannot be relocked).

At this point, adv2, the knight steps forward and enters the room:

<room id="behind_the_red_door">
<member id="adv1" property="mg:status" content="candidate"/>
<member id="adv2" property="mg:status" content="member"/>
<member id="adv3" property="mg:status" content="intitiate"/>
</room>


Naturally, the brave knight discovers that the room is full of a poisonous gas, and sensibly flees. The group of adventurers investigates the second door:

<room id="behind_the_blue_door">
<member id="adv1" property="mg:status" content="prospect"/>
<member id="adv2" property="mg:status" content="prospect"/>
<member id="adv3" property="mg:status" content="prospect"/>
</room>


Fortunately, the same key unlocks this door as well, and the door is unlocked. The knight is less enthusiastic, so the curious wizard enters the room.

<room id="behind_the_blue_door">
<member id="adv1" property="mg:status" content="candidate"/>
<member id="adv2" property="mg:status" content="intitiate"/>
<member id="adv3" property="mg:status" content="member"/>
</room>


So far so good. Mind you, this room is full of a tasteless and odourless poisonous gas, but nobody seems to have noticed. The wizard beckons to his companions to enter the room:

<room id="behind_the_red_door">
<member id="adv1" property="mg:status" content="candidate"/>
<member id="adv2" property="mg:status" content="alumnus"/>
<member id="adv3" property="mg:status" content="initiate"/>
</room>
<room id="behind_the_blue_door">
<member id="adv1" property="mg:status" content="member"/>
<member id="adv2" property="mg:status" content="member"/>
<member id="adv3" property="mg:status" content="member"/>
</room>


And now the diabolically cunning design of the room becomes painfully clear, as the combined effect of the gases in the two rooms becomes apparent, and the unfortunate knight, who has membership || alumnus status for both rooms, turns into a pillar of salt.

<room id="behind_the_red_door">
<member id="adv1" property="mg:status" content="candidate"/>
<member id="adv2" property="mg:status" content="alumnus"/>
<member id="adv3" property="mg:status" content="initiate"/>
</room>
<room id="behind_the_blue_door">
<member id="adv1" property="mg:status" content="alumnus"/>
<member id="adv2" property="mg:status" content="permanent"/>
<member id="adv3" property="mg:status" content="alumnus"/>
</room>


So ends the story of "RDFa and the Diabolic Room with Two Doors."

Tuesday, July 28, 2009

On the proper use of quote with html attribute values...

A very short rant.

When your HTML tags contain attributes such as "...width='10%'>", please, please, please use quotes around the value. There may come a time when somebody has to take your code and turn it into XHTML, which requires quotes; moreover, there may come a time when somebody has to take your code and generate it on the server side using JSP or ASP... which will not take kindly to that "...10%>".

So please, use quotes around your HTML attribute values. Or my son will kick you.

Friday, March 09, 2007

"With all of these changes, XSLT 2.0 is able to assume a much more extensive “work-horse” mode than it has previously. Most of these modes have already been explored with older extended XSLT 1.0 processors, but because such implementations tended to differ in critical areas developers and IT managers tended to shy away from them for all but very specialized applications. "

- from his o'reilly blog, Kurt Cagle on XSLT 2.0, a very good summary of the technology and its ramifications.

One thing Kurt mentions is the ability to use unparsed-text() to build up-convertors - Michael Kay has a great paper on this topic, up-converting genealogical data to XML.

Currently still loving Loney, Dear, and more than a little obsessing over Mason Proper and She, Sir. Too bad it's not "Mason, Proper" - for symmetry, see?

Let's see: Michigan based, debut album self-released "There is a Moth in Your Chest" - Vocally, Mason Proper remind me a lot of the 90's experimental work of Ian Masters in the Pale Saints and Spoonfed Hybrid... and that's a really good thing for me, since I loved those bands a ton.

Listening to Mason Proper has the wonderful effect of cheering me up. That's also a very good thing. If you listen to the lyrics a bit closer, well, damn! they're pretty cool, never too obscure, and twee only to the point that it's fun, not obnoxious. Good stuff, I only wish they'd tour my neck of the woods!


Mason Proper - The World Is Smaller Than you Think
Mason Proper - Mr. Charm
Mason Proper - Lights Off
Mason Proper - Chemical Dress

MySpace - Mason Proper

Tuesday, January 23, 2007

Planar Chaos Capsule Reviews

Courtesy of NicotineJones of MiseTings

Planar Chaos - White
Planar Chaos - Blue/Black
Planar Chaos - Red
Planar Chaos - Green/Gold etc

My thoughts? I really like Giants, and not so much Boros Deck Wins, so the extra stuff in RW is pleasant, but the Hammerheim dude doesn't do a lot for me. Shade of Trokair looks nice; Sinew Sliver-Cautery Sliver could be a lot of fun, and I really want to play Pyrohemia for something. Dreamscape Artist (the Harrow guy) seems really good too, maybe with the Ana Battlemage to back him up (so I liked BUG a lot too).

Oh p.s. happy birthday to me! Just discovered this little snippet of info:

http://www.w3.org/ — 23 January 2007 — Based on widespread implementation experience and extensive feedback from users and vendors, W3C has published eight new standards in the XML Family to support the ability to query, transform, and access XML data and documents. The primary specifications are XQuery 1.0: An XML Query Language, XSL Transformations (XSLT) 2.0, and XML Path Language (XPath) 2.0; see the full list below.

These new Web Standards will play a significant role in enterprise computing by connecting databases with the Web. XQuery allows data mining of everything from memos and Web service messages to multi-terabyte relational databases. XSLT 2.0 adds significant new functionality to the already widely deployed XSLT 1.0, which enables the transformation and styled presentation of XML documents. Both specifications rely on XPath 2.0, also significantly enriched from its previous version.

W3C’s XSL Working Group and XML Query Working Group, who created these specifications, have addressed thousands of comments from implementers and the interested public to ensure that the specifications meet the needs of diverse communities.

Nice! Looks like some of my favorite technologies just became official! Thank yous to everyone involved!