search

ISO-TC211 / schemas

Official ISO/TC 211 XML Schemas (input to schemas.isotc211.org)
6 stars 8 forks source link

Update to mcc.xsd #2

Closed ejbleys closed 4 years ago

ejbleys commented 5 years ago

Add import statement of gfc.xsd (ISO 19110:2016) to allow inclusion of full General Feature Model when describing structured materials. The change will not generate errors for those already using fcc.xsd, but will extend the functionality.

ronaldtse commented 5 years ago

Thanks @ejbleys.

One question. Do you want to change: schemaLocation="http://standards.iso.org/iso/19110/gfc/1.1/gfc.xsd to schemaLocation="https://schemas.isotc211.org/19110/gfc/1.1/gfc.xsd?

I think that was the approach agreed in Resolution 857:

Official web access for ISO/TC 211 resources to support implementation of standards

ISO/TC 211 resolves to use isotc211.org for web access to its official resources that support implementation, including but not limited to, XML Implementation Schemas, XML Codelists, XML Example files, Ontologies, UML XMI files, Terminologies and Profiles of standards.

ejbleys commented 5 years ago

Yes please moving to https://schemas.isotc211.org https://schemas.isotc211.org/ would be appropriate OOPS suspect my update got that wrong for xmlns:xs=“” and imports Probably best not to pull baseTypes2014.xsd but pull as baseTypes2015.xsd and we’ll deal with it from there. Warning - I’m not clear on how to pass suggestions into GitHub, so if I’m not doing it correctly - please comment

Cheers e Evert Bleys 4 Tudor Place HUGHES ACT 2605 Australia +61 (0)2 62811773 +61 (0)411 483 876 ejbleys@gmail.com Skype ejbleijs@gmail.com

On 2019-08-14, at 1:52 pm, Ronald Tse notifications@github.com wrote:

Thanks @ejbleys https://github.com/ejbleys.

One question. Do you want to change: schemaLocation="http://standards.iso.org/iso/19110/gfc/1.1/gfc.xsd to schemaLocation="https://schemas.isotc211.org/19110/gfc/1.1/gfc.xsd?

I think that was the approach agreed in Resolution 857:

Official web access for ISO/TC 211 resources to support implementation of standards

ISO/TC 211 resolves to use isotc211.org for web access to its official resources that support implementation, including but not limited to, XML Implementation Schemas, XML Codelists, XML Example files, Ontologies, UML XMI files, Terminologies and Profiles of standards.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ISO-TC211/schemas/pull/2?email_source=notifications&email_token=AIBGJZYOLQSV5CWQ2ZWKEQ3QEN6ORA5CNFSM4ILQPZPKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4HTWNQ#issuecomment-521091894, or mute the thread https://github.com/notifications/unsubscribe-auth/AIBGJZZZSZZTOZLBP5W2K2DQEN6ORANCNFSM4ILQPZPA.

ronaldtse commented 5 years ago

@ejbleys this is totally fine! Do you want me to update the change, or are you comfortable with updating the schemaLocation in code, then pushing the change to this branch?

I'm confused with the mention of baseTypes201{4,5}.xsd. Is there anything you'd like us to do there?

ejbleys commented 5 years ago

Hi Ron Thanks for the yellow card, I am rethinking the 2014/2015 concept I think as there is likely to be some grief caused by the repair for RecordType (no longer a straight gco:CharacterString) we will need to tread carefully I suggest we seperate the existing and replacement XSDs I’m open to recommendations on how this should be done. a) a new directory with gco XSDs (gco.xsd & baseType.xsd) I’m not convinced as these are fixes and not “new” they should not be versions as the change is only a patch eg same version different edition b) new names for them in the same directory eg gco1.1.xsd and baseType1.1.xsd gco.xsd would need to be updated to point to new baseType1.1.xsd Cheers

e Evert Bleys 4 Tudor Place HUGHES ACT 2605 Australia +61 (0)2 62811773 +61 (0)411 483 876 ejbleys@gmail.com Skype ejbleijs@gmail.com

On 2019-08-15, at 2:23 pm, Ronald Tse notifications@github.com wrote:

@ejbleys https://github.com/ejbleys this is totally fine! Do you want me to update the change, or are you comfortable with updating the schemaLocation in code, then pushing the change to this branch?

I'm confused with the mention of baseTypes201{4,5}.xsd. Is there anything you'd like us to do there?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ISO-TC211/schemas/pull/2?email_source=notifications&email_token=AIBGJZYUSQTWGAZSFMNZDMTQETK4LA5CNFSM4ILQPZPKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4KZNQQ#issuecomment-521508546, or mute the thread https://github.com/notifications/unsubscribe-auth/AIBGJZ6FO7FZCGWUE3FHD4TQETK4LANCNFSM4ILQPZPA.

ejbleys commented 5 years ago

Hi I’d really appreciate comments against the following Dear all I believe that gco does not belong to ISO 19115 and could well exist at …/iso/common/gco/... If gco continues to reside within the .../iso/19115/-3/gco/ then the latest changes exist as a patch and should be .../iso/19115/-3/gco/1.0.1/~ gco.xsd baseTypes.xsd Paths and naming are personal preferences and in our case should be caucused. At the meeting in Maribor there was an attempt to identify a better way of dealing with versions/editions/patches in file path it had no resolution otter than a consideration for inclusion of the year-of-release and amendment-number in the path I believe that would result in a construct that looked a bit like ".../iso/19115/2014/cit/1.0/…” In this example an amendment that affected cit would increment it to ".../iso/19115/2014/cit/2.0/…” a different release if cit within that amendment space would sub-increment to ".../iso/19115/2014/cit/2.1/…” a patch to that release would sub-sub-increrment to ".../iso/19115/2014/cit/2.1.1/…” For ease of use a “current” version could exist ".../iso/19115/2014/cit/…” being a copy of the highest increment of cit/#.#[.#]/... the XML implementation not having its own date but becoming a appendix to the standard

Looking forward to a discussion Cheers e Evert Bleys 4 Tudor Place HUGHES ACT 2605 Australia +61 (0)2 62811773 +61 (0)411 483 876 ejbleys@gmail.com Skype ejbleijs@gmail.com

On 2019-08-15, at 2:23 pm, Ronald Tse notifications@github.com wrote:

@ejbleys https://github.com/ejbleys this is totally fine! Do you want me to update the change, or are you comfortable with updating the schemaLocation in code, then pushing the change to this branch?

I'm confused with the mention of baseTypes201{4,5}.xsd. Is there anything you'd like us to do there?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ISO-TC211/schemas/pull/2?email_source=notifications&email_token=AIBGJZYUSQTWGAZSFMNZDMTQETK4LA5CNFSM4ILQPZPKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4KZNQQ#issuecomment-521508546, or mute the thread https://github.com/notifications/unsubscribe-auth/AIBGJZ6FO7FZCGWUE3FHD4TQETK4LANCNFSM4ILQPZPA.

jetgeo commented 5 years ago

The description of the gcc schema on https://schemas.isotc211.org/19115/-3/gco/1.0/ says that "GCO 1.0 is an XML Schema implementation derived from ISO ISO 19115-1, ISO/TS 19139 Geographic information - Metadata - XML schema implementation, Clause . It includes elements for describing basic types from ISO/TS 19103 and conceptual elements from ISO 19118 required in XML implementations of ISO metadata standards..."

If something shall be changed, it must be to have 19103 types in a 19103 schema and 19118 types in a 19118 schema. We do not have a "common" package in the HM, everything must be defined in one of the standards.

About the URI structure: The structure we have agreed on is https://schemas.isotc211.org/iso[standardNumber]/-[partNumber]/[namespace]/[editionNumber] Where the edition number is the official edition number of the standard. The reason we are using the edition number instead of the year is that the edition number is set as soon as a standardisation project starts, while the year depends on when the standard is actually published. If we need to identify patches of the schema, we may use the decimal part of the edition number. But we have agreed to not include the year in the path.

ejbleys commented 5 years ago

Thank Knut I was looking for that reference How do you feel about splitting out ISO 19103 & ISO 19118? Cheers e Evert Bleys 4 Tudor Place HUGHES ACT 2605 Australia +61 (0)2 62811773 +61 (0)411 483 876 ejbleys@gmail.com Skype ejbleijs@gmail.com

On 2019-08-19, at 4:39 pm, Knut Jetlund notifications@github.com wrote:

The description of the gcc schema on https://schemas.isotc211.org/19115/-3/gco/1.0/ https://schemas.isotc211.org/19115/-3/gco/1.0/ says that "GCO 1.0 is an XML Schema implementation derived from ISO ISO 19115-1, ISO/TS 19139 Geographic information - Metadata - XML schema implementation, Clause . It includes elements for describing basic types from ISO/TS 19103 and conceptual elements from ISO 19118 required in XML implementations of ISO metadata standards..."

If something shall be changed, it must be to have 19103 types in a 19103 schema and 19118 types in a 19118 schema. We do not have a "common" package in the HM, everything must be defined in one of the standards.

About the URI structure: The structure we have agreed on is https://schemas.isotc211.org/iso[standardNumber]/-[partNumber]/[namespace]/[editionNumber] https://schemas.isotc211.org/iso%5BstandardNumber%5D/-%5BpartNumber%5D/%5Bnamespace%5D/%5BeditionNumber%5D Where the edition number is the official edition number of the standard. The reason we are using the edition number instead of the year is that the edition number is set as soon as a standardisation project starts, while the year depends on when the standard is actually published. If we need to identify patches of the schema, we may use the decimal part of the edition number. But we have agreed to not include the year in the path.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ISO-TC211/schemas/pull/2?email_source=notifications&email_token=AIBGJZ7DOOH36OZKGPWGPO3QFI535A5CNFSM4ILQPZPKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4R3LWA#issuecomment-522434008, or mute the thread https://github.com/notifications/unsubscribe-auth/AIBGJZ2Q4FFHHTYTRZOSVH3QFI535ANCNFSM4ILQPZPA.

jetgeo commented 5 years ago

In general, each standard (and part and edition) should have its own implementation schema. You should not have to go to 19115 to find the implementation schema of 19103. So I think it would be good to separate them.

PeterParslow commented 5 years ago

"In general, each standard (and part and edition) should have its own implementation schema." - whilst I agree in principle, it may take several years to transition to this.

ISO 19115-3 "had to" create 'bits of implementation schema' for older conceptual standards (19103, 19118) because they didn't exist. Perhaps XMG could propose amendments to those 'older standards' to insert a clause pointing to their (newly created / extracted from 19115-3) schemas? Each would probably also need a sentence or two (near the URL clause) explaining which clauses of the new 19139 have been used. 19115-3 would also have to be amended to state that it imports rather than defines those namespaces - and presumably to change the Namespace URIs of those that move from one standard to another.

Perhaps best done in batches? After resolving the question of how to manage "minor changes" to schemas (namespace URIs & locations).

jetgeo commented 5 years ago

Agree. It would be natural to start with 19103 then.

ejbleys commented 5 years ago

Thanks I’ll start to work towards those recommendations It seems sensible to move away from the namespace gco if these are to be split successfully. I note the model does not seem to set a precedent for a namespace for ISO 19103. As “Conceptual schema language” could lead to a namespace of ‘csl’ but “Conceptual schema language” is very general and ISO 19103 seems to define basic/base-data-types (bdt) would a namespace of 'bdt' work?

Can someone please remind me what the decision was for those standards happens when there is no part number is the part-number level a) not represented (leads to inconsistent path length) b) left at ‘-‘ c) set to ‘-0’

Cheers e Evert Bleys 4 Tudor Place HUGHES ACT 2605 Australia +61 (0)2 62811773 +61 (0)411 483 876 ejbleys@gmail.com Skype ejbleijs@gmail.com

On 2019-08-19, at 6:19 pm, Peter Parslow notifications@github.com wrote:

"In general, each standard (and part and edition) should have its own implementation schema." - whilst I agree in principle, it may take several years to transition to this.

ISO 19115-3 "had to" create 'bits of implementation schema' for older conceptual standards (19103, 19118) because they didn't exist. Perhaps XMG could propose amendments to those 'older standards' to insert a clause pointing to their (newly created / extracted from 19115-3) schemas? Each would probably also need a sentence or two (near the URL clause) explaining which clauses of the new 19139 have been used. 19115-3 would also have to be amended to state that it imports rather than defines those namespaces - and presumably to change the Namespace URIs of those that move from one standard to another.

Perhaps best done in batches? After resolving the question of how to manage "minor changes" to schemas (namespace URIs & locations).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ISO-TC211/schemas/pull/2?email_source=notifications&email_token=AIBGJZ4RWOG5UTX77DCJS2TQFJJRXA5CNFSM4ILQPZPKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4SCYVQ#issuecomment-522464342, or mute the thread https://github.com/notifications/unsubscribe-auth/AIBGJZ6SXE2WPGXNMA6QYCTQFJJRXANCNFSM4ILQPZPA.

jetgeo commented 5 years ago

My notes say that we agreed in Maribor to use "-" only in such cases. Should have been updated in the URI document, my responsibility.

ejbleys commented 4 years ago

Hi Knut Do you have any suggestions on XML implementation of models with stereotype of ‘interface' Is it reasonable to just push them through as type in their own right? OR Should I be more respectful of the UML concept that they can be implemented in any way so long as their attributes are respected? This becomes critical in any attempt to generate a standardised (XSD) schema for ISO 19103.

Cheers e Evert Bleys 4 Tudor Place HUGHES ACT 2605 Australia +61 (0)2 62811773 +61 (0)411 483 876 ejbleys@gmail.com Skype ejbleijs@gmail.com

jetgeo commented 4 years ago

I believe interfaces can be implemented in XML as types. However, I am not sure. Perhaps Ted (@tedhabermann) or Clemens (@cportele) has an opinion?

cportele commented 4 years ago

Yes, they can. At least those <<interface>> that specify attributes and association roles (<> in UML 1 / the earlier editions of the 19100 series).

I think there is a recommendation (?) somewhere in the base standards that interfaces should specify attributes/relationships to a detail so that they are sufficient to record the state of the interface and support encoding as specified in 19118.

ejbleys commented 4 years ago

Thanks for that Clearly the interfaces could be implemented as such, but pushing it that way has interesting consequences gco:RecordType (from ISO 19103) is implemented as a CharacterString, yet ISO 19103 has a association of fieldType (type FieldType, with attributes fieldName (aName) and fieldType (TypeName) I can see I have my work cut out to ensure a clean transition, hence I’ve started fora on the livelong site. Cheers e Evert Bleys 4 Tudor Place HUGHES ACT 2605 Australia +61 (0)2 62811773 +61 (0)411 483 876 ejbleys@gmail.com Skype ejbleijs@gmail.com

On 2019-09-27, at 5:09 pm, Clemens Portele notifications@github.com wrote:

Yes, they can. At least those <> that specify attributes and association roles (<> in UML 1 / the earlier editions of the 19100 series).

I think there is a recommendation (?) somewhere in the base standards that interfaces should specify attributes/relationships to a detail so that they are sufficient to record the state of the interface and support encoding as specified in 19118.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ISO-TC211/schemas/pull/2?email_source=notifications&email_token=AIBGJZZ34FRB2GTS3S6LEX3QLWWSHA5CNFSM4ILQPZPKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7X7KSI#issuecomment-535819593, or mute the thread https://github.com/notifications/unsubscribe-auth/AIBGJZ77ODRJVN5QCB4UQSLQLWWSHANCNFSM4ILQPZPA.

PeterParslow commented 4 years ago

My thought:

The reason that neither ISO 19139:2019 nor ISO 19136 Annex E have a rule for converting <> to something in XML is that it shouldn't be done - directly.

ISO 19103 contains elements at the Abstract Schema level. You/we first need to create an Application Schema.

It sounds like when we created 19115-3 gco:RecordType we were a bit naughty (over simplifying it), or perhaps we just got gco:RecordType wrong?

See https://github.com/ISO-TC211/UML-Best-Practices/wiki/Level-of-abstraction. See also the example in ISO 19136-1:2019 Annex D. Perhaps we should make the fact that <> can only appear in Abstract Schemas clear somewhere; it is implied by 19103 Figure 4 (and perhaps in its description at 6.10.2 d) - except of course 'abstract' could also mean 'abstract class').

And of course 19103 fails to follow its own Requirement 4! It is hinted at in the paragraph just above figure 6 in clause 7.1 (introducing those models that appear in 19103). And we should have made this step clearer in ISO 19139. ISO 19118 does make it clear that its all about encoding application schemas, not conceptual schemas.

cportele commented 4 years ago

The reason that neither ... nor ISO 19136 Annex E have a rule for converting <<interface>> to something in XML is that it shouldn't be done - directly.

For 19136 the simple reason is that the old 19103 was based on UML 1 and there was a distinction between <<interface>> (operations only, no attributes) and <<type>> (similar, but can have attributes). This is why 19136 Annex E discusses <<type>>, but not <<interface>>. With the switch to UML 2 and the new 19103 edition <<type>> was merged into <<interface>>. With that in mind, applying 19136 Annex E to UML 2 models will also encode <<interface>> classifiers.

ronaldtse commented 4 years ago

Hello @ejbleys @jetgeo -- do we want any further action on this pull request, since the meeting is around the corner?

ejbleys commented 4 years ago

Please merge Evert Bleys 4 Tudor Place HUGHES ACT 2605 Australia +61 (0)2 62811773 +61 (0)411 483 876 ejbleys@gmail.com Skype ejbleijs@gmail.com

On 2019-11-15, at 3:54 am, Ronald Tse notifications@github.com wrote:

Hello @ejbleys https://github.com/ejbleys @jetgeo https://github.com/jetgeo -- do we want any further action on this pull request, since the meeting is around the corner?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ISO-TC211/schemas/pull/2?email_source=notifications&email_token=AIBGJZZFGUQJDAMEB4RIXO3QTV7DHA5CNFSM4ILQPZPKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEECQTOI#issuecomment-553978297, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIBGJZ5PTQCVCVOOHAWPBDDQTV7DHANCNFSM4ILQPZPA.