RE: [xml-dev] Evaluation Criteria for Markup Languages

["Len Bullard" <cbullard@hiwaay.net>]

A type that spans cultural membranes, automata, and power scaling
(hierarchies of authorities with dynamic resources)?

Locale and authority scale inversely.  The open source response is to choose
correctly what is local (say secret) and what is open (say common).  A
problem of an abstract type is the more universal it is, the harder it is to
sustain meaningfully given the requisite power scaling.  Thus separation of
content and format is desirable but enforceable only to the cost of
enforcing the content tagging, the sustainability of names with reliable
semantics.  The payoffs of the system are in separating the low-rate of
change namespaces from the high rate of change so there is predictability of
at least one of the attractors across the power scales.

The means we use are the best candidate for open source.   The best driver
for improvement I can think of for Federal and DoD systems will be open
source XSLT-FOs.   The format should be the low-rate of change attractor
that can be maintained in open source very reliably because it is the work
item we all contract to with the type definitions (pick one or many).

Put these in open source control systems so many eyes can quickly fix the
bugs that slow down everyone's production in that bidding market.

len

-----Original Message-----
From: Cox, Bruce [mailto:Bruce.Cox@uspto.gov] 
Sent: Tuesday, September 06, 2011 2:55 PM
To: dlee@calldei.com; cbullard@hiwaay.net
Cc: 'Michael Kay'; 'Costello, Roger L.'; xml-dev@lists.xml.org
Subject: RE: [xml-dev] Evaluation Criteria for Markup Languages

The bigger issues for us are IP rights and business rules.  Who, exactly,
are you?  Where do you reside?  What nationality are you? Are you
represented?  Who is the representative?  Where does the representative
reside?  Where should notices (paper, email) be sent, for each of your
pending applications?  Which representatives of a law firm are authorized to
act on your behalf with respect to which of your numerous pending
applications?  These questions will be different for different IP offices
around the world.  Even where the question appears to be the same, the
underlying business rules are often different. 

As Michael said, it's a question of finding the level of abstraction that
everyone can agree to for exchange purposes while still supporting the local
needs of a national office.  It's challenging.

Bruce B Cox
Director, Policy and Standards Division, OCIO, USPTO

-----Original Message-----
From: David Lee [mailto:dlee@calldei.com] 
Sent: 2011 September 6, Tuesday 15:23
To: cbullard@hiwaay.net; Cox, Bruce
Cc: 'Michael Kay'; 'Costello, Roger L.'; xml-dev@lists.xml.org
Subject: RE: [xml-dev] Evaluation Criteria for Markup Languages

If this is actually about *physically shipping* property then the
name/address issues are pamount.
I recommend looking at what various shippers allow, such as FedEx, UPS,
Postal Mail etc.
Its amazing how both limited and different they are.   Even within a given
shipper the rules change depending on the service level (historically due to
aquireing different companies for different service levels like Ground vs
INTL).

It doesn't matter if your address model is extremely rich (say allow native
Chinese characters in Unicode and 10 address lines) if the shipper requires
7 bit ascii , 2 address lines max of 35 "bytes" each.

I would suggest focusing on what the information ultimately has to be used
for.
You may find you need duplicate sets of information.  For example a native
language shipping address along with a 'primative' foreign ascii latin
address.



----------------------------------------
David A. Lee
dlee@calldei.com
http://www.xmlsh.org

-----Original Message-----
From: cbullard@hiwaay.net [mailto:cbullard@hiwaay.net] 
Sent: Tuesday, September 06, 2011 10:57 AM
To: Cox, Bruce
Cc: Michael Kay; Costello, Roger L.; xml-dev@lists.xml.org
Subject: RE: [xml-dev] Evaluation Criteria for Markup Languages


1.  Isn't this the same problem as railroad schedules across different time
zones before time zones or trying to send mail to an address in London?

2.  The typical solution is the global solution:  ignore local traditions
without violating them, that is, as in the case of unversal time, don't use
the local time traditions.

We've all had to build in code for local naming traditions, addresses, heck,
even had to change the colors on the web page because a new party took
power.  We've had to go through hundreds of pages of documents to ensure
there are no references to the star of david or  
israel (yes, we do).   Again, multiple authorities over a process or  
data set is the recipe for chaos in integrated systems.

We solved the problem for hypermedia by accepting Berners-Lee's admonitions
to let the links snap and accept one universal
getting-a-file-and-mailing-it-back addressing technology.  It was simpler
than letting everyone make exceptions and it uncovered enough unknown
exceptions to create careers for some of us.  K.I.S.S.  
sometimes comes at the cost of frosting the locals.   Consensus can  
cost too much.

Something of a challenge then: what is the simplest possible way to create
addresses that will operate across the most addressed recipients where in
fact, you have to identify both the address and the recipient and in this
case, they CAN'T be the same names?

len


Quoting "Cox, Bruce" <Bruce.Cox@USPTO.GOV>:

> To reinforce Michael's comment: the industrial property community is 
> currently negotiating a new standard (will be ST.96) for exchanging 
> industrial property information among offices around the world.  We 
> are debating exactly the issue Michael cited: should name and address 
> models be rich enough to model any address anywhere with all the 
> different geographic region indicators and all the cultural variations 
> (multiple last names, for example); or should they be simple 
> (fullname, addressline1 addressline2, etc.)?  Some offices want richer 
> models for internal processing, others do not, based on their local 
> laws and traditions.  The negotiated standard is likely to allow both 
> (the exchange compromise), which will increase complexity for some, 
> reduce it for others, and just annoy the daylights out of everyone 
> else.  We seem to be in a fractious mood this year.
>
> Bruce B Cox
> Director, Policy and Standards Division, OCIO, USPTO
>
> -----Original Message-----
> From: Michael Kay [mailto:mike@saxonica.com]
> Sent: 2011 August 28, Sunday 18:38
> To: Costello, Roger L.; xml-dev@lists.xml.org
> Subject: Re: [xml-dev] Evaluation Criteria for Markup Languages
>
>
> Very often XML is used to convey data which itself is a model of 
> reality. If reality is complex, then the rules for the data may also 
> be complex. An important criterion for assessing the markup language 
> is not whether or not it is complex, but whether or not it is an 
> accurate model of reality.
>
> For example, the real-world "rules" for personal names and addresses 
> are incredibly complex. If you assess a vocabulary for names and 
> addresses by its complexity, then you may end up deciding that the 
> best vocabulary is one that is in fact incapable of modelling the real 
> world.
>
> Of course, producing a simple model of a complex reality is a 
> desirable goal; it's a process called abstraction and it's the key to 
> all good design. But there's a difference between being simple and 
> being simplistic, and it's very fine line between the two.
>
>
> Michael Kay
> Saxonica
>
>
> On 28/08/2011 23:17, Costello, Roger L. wrote:
>> Hi Folks,
>>
>> I propose the following two criteria for evaluating XML markup languages.
>>
>> -------------------
>> Criterion #1
>> -------------------
>> Markup languages must clearly distinguish between:
>>
>> - Markup for expressing individual concepts, i.e., markup combinators.
>> - Mechanisms for combining markup combinators. When markup is 
>> combined, the meaning of the combined markup must be specified.
>>
>> Analogy: each digit 0 - 9 expresses an individual, well-defined 
>> concept. The digits may be juxtaposed and the meaning of the combined 
>> digits is well-defined. Thus, each digit is a digit combinator and 
>> juxtaposition is the mechanism for combining them.
>>
>> Example: XML Schema does a good job with this criterion. For example, 
>> xs:element is clearly markup for expressing individual concepts, and 
>> xs:sequence is clearly a mechanism for combining them. The meaning of 
>> the combined elements is that they possess a sequential ordering.
>>
>> Example: The Extensible Business Reporting Language (XBRL) does a 
>> fantastic job of separating markup combinators from the mechanisms 
>> for combining them. In XBRL the markup combinators are defined in an 
>> XML Schema and the mechanisms for combining them are specified in a 
>> separate XLink document.
>>
>> -------------------
>> Criterion #2
>> -------------------
>> The rules defined in markup languages must be general. Scientists and 
>> mathematicians are never satisfied with principles or theorems that 
>> apply in only some cases. They seek general rules. So too, markup 
>> language designers must seek general rules for combining markup. 
>> Rules that apply only some of the time--that is, rules with 
>> exceptions--must be avoided.
>>
>> Example: XML Schema does not do well with this criterion. Many of its 
>> rules have exceptions. Here are examples of rules with
>> exceptions:
>>
>> Rule: a xs:sequence contains any xs:elements.
>> Exception: if two xs:elements have the same name but different data 
>> types then they cannot both be in xs:sequence.
>>
>> Rule: The value of the base attribute in<xs:extension base="...">   
>> must reference a xs:complexType.
>> Exception: if the parent of xs:extension is xs:simpleContent then the 
>> value of the base attribute may reference either a xs:complexType or 
>> a xs:simpleType.
>>
>> John Cowan reports that XML Schema has nearly 100 rules with 
>> exceptions. These make the language difficult to use and understand.
>>
>> Comments?
>>
>> /Roger
>>
>>
>> _____________________________________________________________________
>> _
>> _
>>
>> XML-DEV is a publicly archived, unmoderated list hosted by OASIS to 
>> support XML implementation and development. To minimize spam in the 
>> archives, you must subscribe before posting.
>>
>> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
>> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
>> subscribe: xml-dev-subscribe@lists.xml.org List archive:
>> http://lists.xml.org/archives/xml-dev/
>> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>>
>>
>
>
>



_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support
XML implementation and development. To minimize spam in the archives, you
must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org List archive:
http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php