Ken
The reason why intermediary code had to be written was because the systems where NOT standards compliant. I hope that the outcome of the Interoperability tests proves to vendors what has to be done and which standards or beter still recommendations to adopt. That was the whole idea of the funded pilots. In particular I am hoping that some form of stanrds similar to the IMS Enterprise model of interoperability will be adopted for that part of the jigsaw.
By definitions standards evolve but VERY slowly, whilst recommendations evolve quickly. It is for this reason that IMS and SCORM are recommendations and not yet officially kite marked standards.
Good debate.
-----Original Message-----
From: Ken Smith [mailto:[log in to unmask]]
Sent: 03 May 2002 09:27
To: [log in to unmask]
Subject: Re: Standards-Compliance-Students
Steve
You are right to think that I have not read all the reports, I have not
even read all the ones that have been published so far. I have read the ones
that apply to systems either tested in our region or of systems popular in our
region. I agree with you that batch transfer does not prove interoperability
and the anecdotal evidence from the people on the ground was that batch was
chosen because that is what we have the most chance of delivering. The same
people tell me that a large chunk of intermediate code had to be written before
even batch transfer was achieved. I thought that we were saying that if we all
work to the same standards then transfer can be achieved without such
intermediary code.
I agree that imposing standards is a matter for those paying for the product,
when those paying for the product are those using the product. In this case
they are not. There is another reason for imposing standards, that of the
cartel. "If we all work to the same standard then we do not have to spend
fortunes on research trying to out do one another".
I am not against standards I just prefer them to evolve. The de facto standard
is the one chosen by the market. If it is what the market wants it will be
successful. TCP/IP being a case in point. Whether other systems are better is
largely irrelevant, this is the standard the users have chosen.
Quoting Steve Molyneux <[log in to unmask]>:
> Ken
>
> In response to your comment "Incidentally the systems recently under
> trial did not seem to talk to each other
> very well, standards or no standards." I think that if you read the
> reports from the FE/MLE interoperability project, most went very well
> indeed. I think that the only problems where with how implementation
> should occur. Batch or Real-Time. Most elected for the Batch mode (which
> in my opinion is a mistake as that does not prove inter-operability but
> just being able to import and export data). Many, in particular the UK
> VLE offerings did work as planned and the exercise was a useful one from
> both the colleges having a full understanding of all the issues
> (including the non-technical ones around change management) and vendors
> having a better understanding of each others systems.
>
> As to imposing standards, this surely is a mater for those who are
> paying for the services. It is uncommon for anyone to impose any
> technical standards unless for a valid reason, which in the main is
> "Value for Money" or "Security".
>
> This is evident in the world of Multimedia. MPG is a standard, but not
> everyone uses it, it is a matter of choice.
>
>
>
>
> -----Original Message-----
> From: Ken Smith [mailto:[log in to unmask]]
> Sent: 02 May 2002 19:07
> To: [log in to unmask]
> Subject: Re: Standards-Compliance-Students
>
>
> For Nigel
>
> The argumentI was addressing was whether standards were or were not a
> good
> thing per se.
>
> However, I can apply this to the VLE argument. If the the need to
> conform to
> the particular communication standard means that an otherwise useful
> feature
> has to be left out of your VLE then the standard has stifled creativity.
> In
> the same way that the inclusivity rules that we are trying to introduce
> is
> stifling some of the creativity of programmers who would like to add
> useful
> features to their learning materials but cannot make them acceptable to
> all
> people with or without physical or mental impairment.
>
> With regard to the "thinking outside of the box", if you are to be able
> to
> dream and be able to realise those dreams you need as few constraints
> as
> possible. In other words you need not to be tied to a set of
> standards.
>
> Incidentally the systems recently under trial did not seem to talk to
> eachother
> very well, standards or no standards. So I am told, most achieved
> their
> levels of interoperability by using an intermediary program, something
> akin to
> a router for software.
>
> I hope this answers your question. If you want to know where I stand it
> is
> simply that standards should not be so tight as to be restrictive and
> should
> not be imposed too early in the development of a system.
>
> Quoting Nigel PEET <[log in to unmask]>:
>
> > "On the other hand they also stifle creativity and seriously inhibit
> > thinking "outside of the box"."
> >
> > I'm at a loss to see how this can possibly happen simply because we
> want
> > the
> > underlying (communication) technologies to talk to each other. Could
> > Ken
> > help me out with this?
> >
> > Steve: I would prefer standards issues to be aired here. They are an
> > integral part of the VLE debate whether you are a designer or an
> > implementer.
> >
> > Nigel Peet
> > Director of ICT
> > South Cheshire College
> >
> > -----Original Message-----
> > From: Ken Smith [mailto:[log in to unmask]]
> > Sent: 02 May 2002 09:04
> > To: [log in to unmask]
> > Subject: Re: Standards-Compliance-Students
> >
> >
> > I feel that standards are a double edged sword. Yes they do allow
> > people
> > toto work towards a common goal and share their experiences much
> more
> > easily. This is extremely important if we are to make content
> available
> > as
> > quickly as possible. On the other hand they also stifle creativity
> > and
> > seriously inhibit thinking "outside of the box". Probably the
> biggest
> > mistake is to try to enforce a standard before the pace of
> development
> > has
> > levelled off. Just think where we would be if the old Microsoft MSX
> > standard had been successful, still using z80 processors.
> >
> > Perhaps we should be looking at looser standards. Ones that allow a
> > large
> > amount of leeway within a set framework. Take RS232c a very loose
> > standard
> > protocol for serial transmission. Invented for the old Teletype
> > machines in
> > the 1950s and still being used (although it is now dying out) on all
> our
> > PCs
> > It survived this long by not being too restrictive.
> >
> > Quoting Steve Molyneux <[log in to unmask]>:
> >
> > > I must disagree. Standards are extremely important. Especially if
> we
> > > "the tax payer" are to get value for public funds spent on content
> > and
> > > systems. This is exactly why interoperability is paramount. I feel
> > > there are a number of issues with equal validity. These include
> > > Pedagogy, Interoperability, Access (addressing disability) and
> > > multi-channel support.
> > >
> > > Maybe if colleagues feel it is a problem we should request a
> > separate
> > > list managed by CETIS on the standards issue as that is exactly
> > their
> > > domain.
> > >
> > > As one who is heavily involved in advising Government, Industry
> and
> > > Customers of learning technologies I would welcome it.
> > >
> > > What do colleagues think?
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Andy Black [mailto:[log in to unmask]]
> > > Sent: 01 May 2002 09:54
> > > To: [log in to unmask]
> > > Subject: Standards-Compliance-Students
> > >
> > >
> > > Dear List
> > > I feel that our 'VLE' list is in danger of becoming the official
> > > 'Standards and Compliance' debate list. Surely, (apologies for
> > > repeating myself) at the end of the day, the only thing that
> really
> > > matters is whether or not students and teachers are using ICT to
> > > enhance their teaching and learning?
> > >
> > > Again I have to agree that 'it would be nice'
> > > to "Standardise" VLEs and tell vendors what to do when developing
> > > their products. However, I and many of you, live in the real
> > (Virtual)
> > > world where commercialism rules and evolution of products is
> market
> > > driven. Instead of getting wrapped up in our own self inflicted
> > > 'issues' with compliance and standardisation, we should really be
> > > encouraging those colleagues who have had minimal exposure
> > > to these technologies, to have a go!
> > >
> > > Who are we anyway to impose 'standards' and
> > > demand 'compliance' when we are not the ONLY consumers of VLEs? Or
> > are
> > > we once again, attempting to justify our own jobs whilst
> neglecting
> > > the 'real' end users - the students...
> > >
> > > Member of the Content Council and registered as an e- learning
> > > consultant. www.contentcouncil.co.uk
> > >
> > > Get your own zoom email - click here - http://www.zoom.co.uk/
> > >
> > > ***************** List information: ***************** Remember -
> > > replies go by default to the entire list. Access the list via the
> > web
> > > on http://www.jiscmail.ac.uk/lists/vle.html
> > > The Ferl VLE Focus Area is at
> > > http://ferl.becta.org.uk/display.cfm?page=76
> > > To unsubscribe, email [log in to unmask] with the message:
> > leave
> > > vle
> > >
> > > ***************** List information: ***************** Remember -
> > > replies go by default to the entire list. Access the list via the
> > web
> > > on http://www.jiscmail.ac.uk/lists/vle.html
> > > The Ferl VLE Focus Area is at
> > > http://ferl.becta.org.uk/display.cfm?pagev
> > > To unsubscribe, email [log in to unmask] with the message:
> > leave
> > > vle
> > >
> >
> >
> >
> > Ken Smith
> > I.L.T. Specialist
> > JISC RSC - SE
> > Office 01189 675451
> > Mobile: 07814023986
> >
> > ***************** List information: *****************
> > Remember - replies go by default to the entire list.
> > Access the list via the web on
> > http://www.jiscmail.ac.uk/lists/vle.html
> > The Ferl VLE Focus Area is at
> > http://ferl.becta.org.uk/display.cfm?page=76
> > To unsubscribe, email [log in to unmask] with the message:
> leave
> > vle
> >
> > ***************** List information: *****************
> > Remember - replies go by default to the entire list.
> > Access the list via the web on
> > http://www.jiscmail.ac.uk/lists/vle.html
> > The Ferl VLE Focus Area is at
> > http://ferl.becta.org.uk/display.cfm?page=76
> > To unsubscribe, email [log in to unmask] with the message:
> leave
> > vle
> >
>
>
>
> Ken Smith
> I.L.T. Specialist
> JISC RSC - SE
> Office 01189 675451
> Mobile: 07814023986
>
> ***************** List information: *****************
> Remember - replies go by default to the entire list.
> Access the list via the web on
> http://www.jiscmail.ac.uk/lists/vle.html
> The Ferl VLE Focus Area is at
> http://ferl.becta.org.uk/display.cfm?page=76
> To unsubscribe, email [log in to unmask] with the message: leave
> vle
>
> ***************** List information: *****************
> Remember - replies go by default to the entire list.
> Access the list via the web on
> http://www.jiscmail.ac.uk/lists/vle.html
> The Ferl VLE Focus Area is at
> http://ferl.becta.org.uk/display.cfm?pagev
> To unsubscribe, email [log in to unmask] with the message: leave
> vle
>
Ken Smith
I.L.T. Specialist
JISC RSC - SE
Office 01189 675451
Mobile: 07814023986
***************** List information: *****************
Remember - replies go by default to the entire list.
Access the list via the web on http://www.jiscmail.ac.uk/lists/vle.html
The Ferl VLE Focus Area is at http://ferl.becta.org.uk/display.cfm?page=76
To unsubscribe, email [log in to unmask] with the message: leave vle
***************** List information: *****************
Remember - replies go by default to the entire list.
Access the list via the web on http://www.jiscmail.ac.uk/lists/vle.html
The Ferl VLE Focus Area is at http://ferl.becta.org.uk/display.cfm?pagev
To unsubscribe, email [log in to unmask] with the message: leave vle
|