Point taken Eduardo: there does seem to be wide consensus that separation of model from presentation is a Good Thing. That's why it's ironic that in the XML community we're always talking about how our document instances should be readable . Readablility is a goodness measurement of presentation right? A model wouldn't have to be readable right? There are a whole range of tradeoffs possible. A presentation-free model exists at one end... pure presentation details is at the other. Inasmuch as we've already chosen a midpoint, I see nothing absurd about discussing possible surrounding midpoints. In order from presentation-free to presentation-full here are some points in the continuum (choices we could make for our document/message meta-structure): * a binary structure -- you've got to read the schema (not included) to understand the structure * a text-encoded structure that's fairly readable but which carries no markup save positional and nesting markup (think LISP S-EXPR's) -- you've still got to read a schema to know what's going on * some sub-XML type thing that's e.g. less verbose -- now you have tags but perhaps structure end is a generic close delimiter -- not a repeated tag name. * XML -- now you've got tag names, but in what language -- you've already picked a presentation right? * XML with human readable code list values -- again, in what language If we're going to go for a clean separation of model from presentation the I'd guess that we'd want to e.g. use numbers to identify code list values in a language-neutral way. That being said I find it a little bit of a double standard, given that we've chosen XML as a basis (what with all it's redundancy-for-the-sake-of-readability) I just re-read Phil's message: > > The numeric representation of the country identifier > > is the only part that we rely on in canonical XML > > markup based on the ASN.1 schema. Only the numeric > > portion of an abstract value such as ROM(642) > > need ever appear in the transfer syntax where there > > is typically no human reader involved. I think the key word is rely . The way I would interpret this idea for UBL would be that we would make the pure identifier (the numeric one) required, and we'd make the textual one ( ROU ) optional. Seems like we ought to give some guidance that says: A UBL-compliant processor will operate only on the pure identifiers -- not on the textual ones . In what artifact could we make such a statement? Is that part of our charter? I think it should be. > -----Original Message----- > From: Eduardo Gutentag [ mailto:
eduardo.gutentag@sun.com ] > Sent: Monday, February 11, 2002 11:05 AM > To: Phil Griffin > Cc: NDR SC > Subject: Re: [ubl-ndrsc] [Fwd: Fwd: ISO 3166-1 -- Change of > Alpha-3 Code > Element for Romania] > > > The separation of content from presentation is fundamental to > how XML is supposed to work, either via stylesheets (preferrably) > or via the applications themselves. So I'm not sure what > novelty you're proposing. I thought this was a given. > > Phil Griffin wrote: > > > FYI. This seems relevant to our work. And I believe > > illustrates just how subject to change character > > string code lists can be. > > > > I note that while the numbers are not as expressive > > perhaps for human readers, they are stable and work > > reliably in software. > > > > The numeric representation of the country identifier > > is the only part that we rely on in canonical XML > > markup based on the ASN.1 schema. Only the numeric > > portion of an abstract value such as ROM(642) > > need ever appear in the transfer syntax where there > > is typically no human reader involved. > > > > Perhaps we should consider that the characters to be > > displayed or read by an application could be disjoint > > from the value actually used for validation purposes. > > > > That is, I might send you 642 and you might choose to > > display ROMANIA or ROM or ROU or nothing based on > > you own local copy of the characters that map to these > > numeric values. > > > > Not a perfect solution, just an idea for consideration. > > > > Phil > > > > > > > -------------------------------------------------------------- > ---------- > > > > Subject: > > > > Fwd: ISO 3166-1 -- Change of Alpha-3 Code Element for Romania > > From: > > > > Francois Vuilleumier <
fvuille@attglobal.net> > > Date: > > > > Sun, 10 Feb 2002 18:38:08 +0100 > > To: > > > >
moumg@ties.itu.int > > > > > >> From: Wischhoefer Cord <
wischhoefer@iso.org> > >> Subject: ISO 3166-1 -- Change of Alpha-3 Code Element for Romania > >> Date: Mon, 4 Feb 2002 10:58:28 +0100 > >> > >> Dear All, > >> > >> For your information here's the latest on ISO 3166-1: > >> > >> On request of the Romanian Government the ISO 3166/MA decided to > >> change the ISO 3166-1 three-letter (alpha-3) code element > for Romania > >> from ROM to ROU. > >> > >> The two-letter code element RO remains unchanged. > >> > >> The change took effect on 1 February 2002. > >> > >> Below are the URLs of the two language versions of the ISO 3166-1 > >> Newsletter V-3 announcing the change. > >> > >> English version of the Newsletter: > >>
http://www.din.de/gremien/nas/nabd/iso3166ma/nl_pt1/nlv3e_rou.html > >> French version of the Newsletter: > >>
http://www.din.de/gremien/nas/nabd/iso3166ma/nl_pt1/nlv3f_rou.html > >> > >> Best regards > >> > >> Cord Wischhöfer > >> ISO 3166/MA Secretary > >> > >> Tel.: +41 22 749 72 33 > >> Fax: +41 22 749 73 49 > >> Email:
wischhoefer@iso.org < mailto:
wischhoefer@iso.org > > >> < mailto:
wischhoefer@iso.org > > > > > Part 1.2 > > > > Content-Type: > > > > message/rfc822 > > > > > > > -- > Eduardo Gutentag e-mail: >
eduardo.gutentag@Sun.COM > XML Technology Center Phone: (510) 986-3651 x73651 > Sun Microsystems Inc. > > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <
http://lists.oasis-open.org/ob/adm.pl > >