Re: [ubl-ttsc] Minutes of 20 November meeting

[Chin Chee-Kai <cheekai@softml.net>]

Thanks for the minutes, Anne;  this is helpful when sleeping
bugs are prevalent in my part of the world at the time of meeting.

I'd like to provide comments on the minutes for the purpose of
rolling the discussion perhaps as inputs to next meeting.


>>3. Tools Requirements (see below)
>>
>>   There are two sets of tools to consider:
>>   those for internal development of UBL and tools for exteral users of UBL.
>>   There is some overlap, but for the most part we are now focusing on
>>   tools for the end user/developer of UBL.

This clarification is very good to have, though at times may not be
that easy.  What's done internally might just well be what the user
would want to follow.  But for our purposes, we should still draw
the line somewhat so that one could understand the context in which
the tool developed was designed (e.g. is it meant to assist UBL's
spec development, or is it meant for end-user environment to
process instances?)

The focus on end-user/developer of UBL is appropriate at this
time, I think, as it provides synergy with PISC.





>>   It would be useful to show a cooperative tools environment - how users
>>   can put together existing tools and technologies to develop with UBL.
>>   Something to provide a guideline for developers and gives them some
>>   idea of what directions we think tools will go.

This is an interesting idea - a cooperative tools environment.
Is there elaboration on this?




>>   We need a document that describes the current process - how you can
>>   change a spreadsheet/model and use ublish to create new schemas and
>>   be close to ccts compliance.  Is this doable with out incurring any
>>   additional cost?

UBLish was more an "internal" tool that was originally designed to 
bring out UBL deliverable schemas than to be an end-user commercial 
tool.  Yet, the feedback I heard so far appears that that's exactly
the kind of modeling/transformation process that users are 
looking at.  

I understand a couple of individuals and organizations,  for 
instance, have used UBLish (0p70) to transform the modified
spreadsheets to produce their own schemas.  That appears to be
the most straightforward, painless and relatively reliable way
to get a "nearby" schema around UBL's.  

The steps would just simply be to pick one of the spreadsheets
and start modifying its contents in a way that addresses 
one's data modelling needs.

The more ambitious ones who picks up a bit of XPS programming
might start working into the UBLish internals to look at things 
to modify.   But of course, there's a chance that if one modifies 
the wrong thing, one might end up getting VBL-lookalike schemas
instead....




>>   This description is needed from the modeling side
>>   - to show how you can use uml to create the schemas.  The problem
>>   is that there is no way from the UML at the moment to know that
>>   the BIEs being used are already in existence.  There is no tool
>>   at the moment that can do this.  So quite a bit of the development
>>   would be manual.

The UBLish "detects" this during schema generation process
by proceeding through with the schema generation, but tagging
the offending type usage line with an "Error" comment block.
As the erraneously typed lines would have prefixes "unknown:"
without namespace definition, the resulting schema would cause 
schema validators to fault, allowing users to be notified of
problems and retrospectively correct them at the spreadsheet
sources.

So the end goal for the end-user in customizing his/her own
schemas would then be to look through the generated schema
and find zero "Error" comment block.

This refinement process was also exactly the steps that 
Library Content side went through in a multi-party iterative
process to generate the UBL schemas.





Best Regards,
Chin Chee-Kai
SoftML
Tel: +65-6820-2979
Fax: +65-6743-7875
Email: cheekai@SoftML.Net
http://SoftML.Net/