OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: The Simple Case


in response to a message from Una sent to the xml.org mailing list.

| Hi,
| I have spent quite a few hours reading and re-reading ISO 11179 and also the
| regrep spec.
| Firstly -- I feel we are trying to pigeon-hole what we are trying to
| accomplish against a specification that had a different purpose in mind.
| >From reading the EBXML mailing list -- I feel that there are people there of
| the same opinion.
| There are definitley common good concepts in ISO 11179 that apply to
| registration and metadata that apply just generally to basic modelling of
| information, but there is no-way we can say we are 100% conformant to ISO
| 11179 and I don't think we would want to be or nobody would use the XML.org
| Registry and Repository.

The tech spec doesn't claim complete conformance:  in particular, the
IRDI mechanism for supplying identifiers won't work because the 
infrastructure for it has never been set up.  And there are some other
faults we're mending.

| The basic reason why is:
| ISO 11179 is about registering and storing data-elements ( and thats it).  A

No, Part 3, clause 3.5 defines data element dictionaries.  We are
departing from 11179 in providing only the administrative metadata
for the d.e.d. and not its full content (because that's already
described in DTD or schema syntax), but in the future we will be
registering data elements, and EBXML has this clearly in view.
Eventually we may want to be able to stitch together 11179 and
some revision of XML Schema so as to give continuity from top to
bottom (d.e.d. to d.e.).

| data element is as they state themselves an undividisable unit of data
| examples they give themselves would be: country of origin code, employee
| number, an employee lastname, product description, etc...
|         They then specify the metadata required for each data-element --
|         i.e the type e.g.  integer, allowable values: 1 -100, min and max
| storage (e.g. if a string might be 1 char to 250 chars) etc..  
|         The metadata set they define makes sense when you are describing
| permissable data descriptions and values -- this specification MIGHT make
| sense if we were interested in having everyone register every element and
| attribute value discretely but even still I think we might have a hard time
| modelling XML element/attribute definitions agains ISO 11179.

This is only some of the permissible metadata.  We are concerned with
the administrative metadata and some of the relevant aspects of
"representation".  As for the items you list, I believe they all
appear in XML Schema.

| There are also a lot of examples today of divergence if you compare the
| Reggrep DTDs to ISO 11179. 
|         ISO 11179 has no notion of registering a document such as a schema
| associated with a data-element, the data-element definition is it.

Not at all; a schema fragment for a data element describes a representation 
of it.  The guys working on both XML Schema and 11179 revision (Olken
and McCarthy) see this clearly, I believe.

|         Certain attributes defined in Reggrep are optional because they
| don't make sense for registry schema's e.g. min and max values etc...

Yes; they might also be optional for data elements, e.g., for empty

|         I could go on much further here but I hope the point has been made -

It hasn't.  Please provide a concrete objection to particular language
in the spec and suggest a change.

| I feel we are almost doing injustice to the ISO 11179 spec by trying to be
| conformant as we are not applying it to its purpose --- I think we should
| say we are using concepts from ISO 11179 where appropriate. 

I believe the first sentence in section 2 of the tech spec says 
essentially that:  "The operation of the OASIS-sponsored registry
shall follow that laid out in ISO/IEC 11179 as closely as feasible."

And I cannot agree that we are not applying it to its purpose.  From
the first Open Forum on Metadata Registries I attended (Jan 1999),
through my attempts to model both 11179 and X3.285 in both DTD
and SOX 1.0 syntax, through my presentation at this year's Open
Forum, this application of 11179 has elicited no objection and
considerable interest.

| So for XML.org/Reggrep
| I do not think data-element is the correct term as the definition of
| data-elements according to ISO-11179 are not what we are registering (this
| then follows for data-element concept, etc..)
| I will call this concept for the purposes of here a "registered-item"
| Here I am really looking specifically at XML.org
| 1.  So what is a registered-item or what can be registered on XML.org? (this
| can be expanded over time or different registries will want to register
| different things)
| Below I have cut and copied these sections from previous emails:

(TA: this is from Jon Bosak's message)

| >From related-entity-list.ent:
[ snipped by TA ]
[ Una again: ]

| This is really a fundamental question for XML.org ---  
| On the Web page we say Schemas and Style-sheets and then list many other
| ad-hoc things e.g. Namespaces, Vocabularies, etc.. 

Yes, this is language not approved by ACXO, and I've complained
about it in the past.

| Biztalk today is concentrated on XDR Schemas as we know.  
| So lets go through the list of xsgml-entity list:
| 1. Schemas:
|         xml-dtd
|         | sgml-dtd
|         | xml-schema
|         | xdr-schema
|         | sox-schema
|        | rdf-schema
|         |relax-schema
| This list makes sense to me but lets look at some of the issues:
| 1. Same schema registered in multiple "formats"
| If I want to register my Shoe schema and I have made it available in all the
| above "formats"  - what do I do?    

As discussed in ACXO meetings, register both and indicate that they're

| All metadata, classification info, related documentation etc.. is equivalent
| except:
| *	"format" 
| *	URN for schema
| A user looking for information would want to browse/search under something
| related to Shoes --- discovered an organization that they trusted -- wanted
| info about their submittal -- bingo sees it is available in the above and
| because there system is using MS -- they choose the XDR-Schema, they could
| then download the schema or include the URN for system access. 
| We either manage and register them as separate registered-items or allow a
| registered-item to consist of one or more items i.e. registered-item becomes
| registered-items  

This is why I suggested that we need a notion something like "literary work".

| 2. Schema made-up of multiple parts
|     If a schema is made up of multiple modules --- it will be up to the SO
| to register each of them individually.
|         | sgml-element
|         | xml-element
|         | sgml-attribute
|         | xml-attribute
|         | sgml-enumerated-attribute-set
|         | xml-enumerated-attribute-set
|         | sgml-enumerated-attribute-value
|         | xml-enumerated-attribute-value
|         | sgml-parameter-entity
|         | xml-parameter-entity
|         | character-entity-set

Yes, but this isn't necessarily a list of things that modules are;
none of these applies to Docbook modules, for example.

| What does it mean to register an xml-attribute and sgml-attribute?    At
| this point in time all we accept is either a file to upload or enter a link
| to some URI.

Registering an xml-attribute would be treating an XML attribute
declaration as a registered item.  I know you don't plan to support
that, but what's the conceptual difficulty?

|        style-sheet-list.ent is:
|         style-sheet-information
|         | xsl-style-sheet
|         | xsl-style-sheet-information
|         | dsssl-style-sheet
|         | dsssl-style-sheet-information
| Again the same applies as for schemas.   

What is that question?

| Overall question -- can a style-sheet or schema be submitted in a form such
| a PDF etc... 

Yes, although we might want to forbid it for XML.org as functionally

| Other Stuff:
| I don't believe any of the other information --- documentation, FAQs, etc...
| are valid standalone registered items -   I think that they related-docs to
| a given registered-item. Sure they have metadata --- name, URN or link but
| are supporting of a registered-item.

There we disagree (and had further discussion of the point on this
morning's ACXO call, after this was written).

| To be continued.

With specific suggestions for change to the spec, please.

regards, Terry

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC