Masks

[martin.me.roberts@bt.com]

Dear all,
	I have been building the code for the masks and need help with
the document.

	I feel there are several things that are wrong with the section
on masks.

	1) the setMask action should declare the style of mask being
used, either 'String', 'Number' or 'Date'.  This means we could either
have setMask(//path,String,mask) or setStringMask(//path,mask).  I
prefer the latter.

	2) In the tables shown there is emphasis on the masks that take
the string in a field as input and change it.  I believe this use case
is different from a mask that is being used to validate input.  This
means that if we want to allow masks for output that we we now have a
use case for cam as a transform tool.  I do not think we should be going
there in release 1.  This means that for release one masks are only for
validation.  If this is the case the mask definitions need changing to
reflect this.

	for example:

	the document shows:

	XXXXing matching to portability returning porting.  In
validation mode I believe this should be interpreted as XXXXing matching
only 7 letter words ending in 'ing'.

	In dates this in even more the case as to allow the change
option you need to know the original format of the date before you can
apply the mask.

	3) There is a usecase for CAM doing some minor changes to the
input document.  The key one being to add defaulted elements and
attributes that do not occur in the incoming document.  This is useful
as it then means any application that handles the document does not need
to apply default values.  If we allow this use case the ability to do
some masking for out might be useful as well.  Therefore we should
change the format of the setMask statement to allow an input and output
mask.
	setStringMask(//path,X11,XXXXing) would handle the portability
to porting case. X11 for validation. XXXXing for output.

	What do you think.

	Once again I find that I have to make some assumptions to
progress with my validator.  I will therefore be assuming the following:
No output mask for v1.0.  So any mask is for validation only which
greatly reduces the number of masks we have to worry about.

	BTW.  What ever the choice forward for this part of the spec the
section on masks need greatly beefing up as it does not define all the
nuances that are shown in the examples.


Martin Roberts 
xml designer, 
BT Exact
e-mail: martin.me.roberts@bt.com 
tel: +44(0) 1473 609785  clickdial
fax: +44(0) 1473 609834
Intranet Site :http://twiki.btlabs.bt.co.uk/twiki



-----Original Message-----
From: martin.me.roberts@bt.com [mailto:martin.me.roberts@bt.com] 
Sent: 04 July 2003 09:18
To: Gnosis_@compuserve.com
Cc: cam@lists.oasis-open.org
Subject: RE: [cam] Default Namespaces


David,
	Sorry you have not got it quite right.  The issue is not the
prefix but the URI.  If you want an example which uses a namespace of
any sort, then the CAM template MUST associate a prefix with the uri and
use it within all the Xpath statement.

	The only case where CAM will NOT require a namespace and
associated prefix is when the example you are using has NO NAMESPACE
definition.

	In other words.  CAM will work in exactly the same way as XSLT
in that it does not support the use of namespaces without associating a
prefix.  

	So if you look at the examples I sent you will see that the CAM
template has the namespace for the bod associated with the prefix bod.
The xml file that conforms to that template does not require a prefix as
CAM will match via the namespace uri not the prefix.

Martin Roberts 
xml designer, 
BT Exact
e-mail: martin.me.roberts@bt.com 
tel: +44(0) 1473 609785  clickdial
fax: +44(0) 1473 609834
Intranet Site :http://twiki.btlabs.bt.co.uk/twiki



-----Original Message-----
From: David RR Webber - XML ebusiness [mailto:Gnosis_@compuserve.com] 
Sent: 03 July 2003 19:10
To: Roberts,MME,Martin,XSG3 R
Cc: cam@lists.oasis-open.org
Subject: RE: [cam] Default Namespaces


Martin,

OK - I'm trying to restate the problem here.

If the output structure is using a default namespace prefix, then we
have to use one in the CAM template too.

If the output structure is not using a namespace prefix, then we do not
need one on the CAM template (apart from the as:  for embedded
functions).

This means with have two styles - one where prefix is required, and one
where its not.

Correct?

Thanks, DW.
==================================================================
Message text written by INTERNET:martin.me.roberts@bt.com
>       The issue is that CAM templates must NOT have default
namespaces.  The instance documents can.  This is the same rule as for
XSLT.

        Therefore you will see fro the attached bod example that I have
changed the cam template and left the instance document alone.

        I feel that this is very important as without it we would be not
fully namespace savvy.  
<


You may leave a Technical Committee at any time by visiting
http://www.oasis-open.org/apps/org/workgroup/cam/members/leave_workgroup
.php