Re: [ubl] Code list schema

["Stephen Green" <stephen_green@seventhproject.co.uk>]

> +1 on Tony's codelists, +1 on generating W3C schema instances and other
> usages for the format, not such an interest in generating schematron but
> interest in extending format to make schematron generation useful.

+1    I agree

Steve

----- Original Message ----- 
From: "Bryan Rasmussen" <brs@itst.dk>
To: "'Stephen Green'" <stephen_green@seventhproject.co.uk>
Cc: <ubl@lists.oasis-open.org>
Sent: Tuesday, August 16, 2005 2:25 PM
Subject: SV: [ubl] Code list schema


>
> Hi Stephen
>
> Well I suppose I can agree with that, however for political reasons I
think
> it best not to have any validation done via schematron that could
> theoretically be done using XSD. That is just a 'personal' feeling. That
> said I do like Tony's suggestion, and while the syntax as specified would
> not be enough to provide for the needs of schematron I suppose that it
could
> always be extended by those intending to use Schematron. I like it because
> the meaning is more clearly delineated, always a plus.
>
> I passed it to a couple of the other people in the office on other
projects,
> James Walford made the observation that he also thought that it was pretty
> nice but in the end - given the example of the the days of the week -
hasn't
> one just made a new list of values 0-7 that have some particular meaning?
By
> mapping between the various lists has one then not just made a central
list
> of higher authority? (please note this is probably a poor synopsis of what
> Jamie was getting at, but it will pass)  Not sure if I care about that
since
> all categorizations struggle with questions of authority, maintenance and
> the like, I could however foresee some day when UBL is the list
organization
> referenced by some other organization, while the UBL list is an
aggregation
> of other codelists. A higher level list built up of other lists. The
> concepts start to become somewhat rareified.
>
> I hope this doesn't sound like I'm against the codelist suggestion of
> Tony's. I am actually very much for it, I know this is a rather strange
way
> of being for something but sometimes this is how I react when a small
> niggling thing bugs me, in this context generating schematron schemas that
I
> wouldn't find particularly useful as such, and which because of possessing
> functional equivalence with an XSD enumerated list would be likely to
> generate complaints among various parties along the lines of:
>   Why couldn't you just do it as XML Schema?! XML Schema is good, it
> comes from W3C, I am an information architect, fear my buzzwords!!
>
> -  or something like that.
>
> So yeah, to summarize -
>
> +1 on Tony's codelists, +1 on generating W3C schema instances and other
> usages for the format, not such an interest in generating schematron but
> interest in extending format to make schematron generation useful.
>
>  :)
>
>
>
> Cheers
> Bryan Rasmussen
>
>
> -----Oprindelig meddelelse-----
> Fra: Stephen Green [mailto:stephen_green@seventhproject.co.uk]
> Sendt: 15. august 2005 16:53
> Til: ubl@lists.oasis-open.org
> Emne: Re: [ubl] Code list schema
>
>
> Bryan
>
> Wouldn't you agree it is unlikely that we'd
> get an XSD schema to validate such a
> code - i.e. where any codelist XSD is
> not imported by the UBL XSDs and has
> to act on its own. This is where I would
> see Schematron 'coming into its own'.
>
> On the other hand who says the XSD has
> to actually validate anything - it could
> just document content in a standard way.
>
> All the best
>
> Steve
>
> ----- Original Message ----- 
> From: "Bryan Rasmussen" <brs@itst.dk>
> To: <ubl@lists.oasis-open.org>
> Sent: Monday, August 15, 2005 2:21 PM
> Subject: SV: [ubl] Code list schema
>
>
> >
> > I should probably specify that in the earlier mail where I said
> > >The codelists they will represent could be just as easily represented
in
> > >XSD.
> > I was speaking in the context of say the enumerated list of values for
> > country codes, in cases where the codelist applies to an element
Country -
> >
> > not in instances where an elements content is really dependent on which
> > value has been enumerated in an attribute.
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS TC that
> > generates this mail.  You may a link to this group and all your TCs in
> OASIS
> > at:
> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in
OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php